Re: Indefinite Containers of Indefinite Private Types

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

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mpr1po$4sn$1@dont-email.me...
> On 08/03/2015 10:40 PM, Niklas Holsti wrote:
>>
>> I'm not sure that I have understood your question correctly -- are you 
>> asking
>> for the RM rule that makes this illegal, or for the reason behind that 
>> rule?
>
> Sorry if I was unclear. I know the ARM prohibits using an uncompleted 
> private
> type as the actual for a generic formal. I'm wondering why this applies to 
> the
> case of a generic formal indefinite private type.

An amazing amount of ARG hair has been pulled over this issue. There are 
about 10 AIs on the topic, none of which have gotten particularly close to 
being accepted.

The very short answer is that an object can be created of such a type, so it 
doesn't help that the type is indefinite (the problems with allowing this 
tend to be in freezing and elaboration rules, particularly in not changing 
the rules incompatibly).

Specifically:

    generic
       type T (<>) is private;
       function Creator return T;
    package G is
       Obj : T := Creator; -- Legal.
    end G;

Note that such an object would be illegal before the full completion of the 
private type. So, if you put that object declaration into the body, you have 
a contract model violation. Therein is the problem.

One could imagine having a declaration for the generic (perhaps an aspect?) 
that would allow such instantiations (and disallow such objects), but again 
there has been little traction for such proposals, all of which are quite 
complex to describe and implement.

...
>> At the point of instantiation in the second case, "T" is a partial view 
>> of the
>> type. RM 7.3(5) says "... Similarly, before the full declaration, the 
>> name of
>> the partial view cannot be used in a generic_instantiation or in a
>> representation item."
>
> Right. This rule has the advantage of being simple. It seems to me it may 
> have
> the disadvantage of disallowing feasible instantiations.

Sure, but there can't be any objects in the generic. Even if there isn't a 
constructor function, any parameter of type T could have been used in "new".

>> I suppose this to do with the "rechecks" discussed
>> in the annotated RM 12.3(11) where the legality of an instantiation is 
>> checked
>> by comparing the actual types with the _full_ declaration of the generic 
>> (not
>> only with the declarations of the generic formals). It might be difficult 
>> to
>> apply these rechecks if the actual type is only a partial view.
>
> What a generic can do with a formal indefinite private type is quite 
> limited.
> Nothing it can do seems to me to need to know the full type definition. 
> Maybe
> I've overlooked something, or maybe there's a good reason why something I 
> don't
> think needs the full definition actually does. I'm curious whether such
> instantiations could be legal, and what I missed if they can't.

Declaring an object surely needs the full declaration, and I showed above 
how to do it. Recall that the elaboration of the body occurs at the point of 
the instance (before the full declaration of the private type).

One can make signature packages with formal incomplete types (which can be 
instantiated with private types before the completion), but it's hard to 
make a useful container that way. (It's not impossible, but you have to use 
more access types than I find comfortable.)

>> The second case becomes legal if the full declaration of type T is moved 
>> to
>> occur before the instantiation -- as happens in the first case -- but you
>> probably knew that.
>
> Yes, of course. The examples are simplified from a more complex case where 
> the
> container is used in the full type definition. This can be achieved by 
> adding
> some additional code that is essentially noise, or by using access types.
> Avoiding access types is worth adding noise, but it would be nice if the 
> noise
> were unnecessary.

I agree, but the ARG has not been able to find an acceptable solution to 
this problem. And we surely have tried:

AI95-00359-01, AI95-00359-02, AI95-00359-03, AI95-00359-04, AI05-0074-1, 
AI05-0074-2, AI05-0074-3, AI05-0074-4, AI05-0074-5 (AI05-0011-1 was also 
related, but it was a duplicate).

We're pretty much pooped out on this topic. Sometimes there just is no 
answer that can get a consensus.

                                   Randy.