Re: Limited initialization for non-limited types

["Randy Brukardt" <randy@rrsoftware.com>]

"Eric Hughes" <eric.eh9@gmail.com> wrote in message
news:b481036a-41ee-4fc5-a0d0-c73cfef60234@s19g2000prg.googlegroups.com...
> Is there any way of getting in-place initialization for non-limited
> objects?  This would be similar to that for limited types as specified
> in ARM05/7.5(8.1/2).

There's no way to require it. And I wouldn't expect that to change -
*requiring* implementations to be able to call a single function with
different return mechanisms seems way over the top. (Of course,
implementations are *allowed* to do that if they like.)

There is a second reason: implementations are allowed to optimize
non-limited controlled types in almost any way that is "correct" (that is,
an initialized object gets finalized). OTOH, limited controlled types are
not allowed to be optimized at all. Even if if the object is never directly
used.

The net effect is that the operations of non-limited controlled types cannot
depend on the order that the operations will be called (anywhere), while
limited controlled can always be depended on. Such dependence in non-limited
controlled is just wrong; it's likely to break if the code is moved to a
different compiler (or even a newer version of the same compiler, as Bob
points out).

> Unfortunately, this is not a hypothetical question.  I'm writing a
> test object used within the unit tests a certain package.  The test
> object is instrumented for white-box testing; it contains a trace
> object as a component.  I want to trace the three events of
> Ada.Finalization.Controlled.  The trace object is associated with the
> variable itself, not with any value that the variable might contain.

I'd probably suggest finding a different approach. (Not that I can think of
one off-hand.)

...
> 2) Variable-specific record components.  Consider this:
>
>     type X is new Ada.Finalization.Controlled with
>         record
>             -- value components (ordinary)
>         private
>             -- variable components (persistent)
>             T : Trace ;
>         end record ;
>
> The idea is that components in the private section are simply not
> copied under assignment.

Interesting, but sounds messy to implement, because it would complicate the
"bit-copy" part of the assignment. That's not usually done
component-by-component!

> 3) Anonymous limited types.  I don't see any particular reason why the
> semantics couldn't be worked out for the following declaration:
>
>     B : limited Any_Type := Initial_Value_Function ;
>
> The ARM is littered with references to phrases such as "the limited
> view of a type".  What are the semantic difficulties with this?  For
> single declarations they seem to be modest.  Isn't this almost the
> same as an in-but-not-out parameter to a procedure?

Anonymous types are a cancer as it is, we surely don't need any more of
them. (Besides, they rarely actually work, since it's usually the case that
you need to write a type conversion or membership somewhere, and you can't
do that without a name.)

> 4) Derived limited types.  The ARM states (roughly) that a limited
> type must derive from limited types.  But what about a type that is
> explicitly a limited view of a possibly not-limited type?
>
>     type C is overriding limited new Any_Type ;

That's already possible for untagged types - any limited private type can be
completed by a non-limited type (including a derivation of some other type).
For tagged types, it would lead to a mess because you could use the
class-wide root type to copy limited extension components. (And if you try
to ban such components, you're going to have to break privacy.)

So, just write:
    package P is
       type C is limited private;
       -- Operations on C.
    private
       type C is new Any_Type;
    end P;

                                     Randy.