Re: Ada design bug or GNAT bug?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 20 Jun 2015 21:42:44 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:yo94phsbcvht$.1bktwe2qoqntt$.dlg@40tude.net...
>> Is it intentional that there is no way to derive from a more specific type
>> privately? A key design pattern is no more possible in GNAT GPL 2015:
>>
>> package P1 is
>>   type T1 is tagged null record;
>>   type T2 is new T1 with null record;
>>   function Foo return not null access T2;
> 
> Anonymous access types are evil; there cannot be a "key design" pattern 
> using them. :-)

The pattern is having an implementation privately deriving from a more
specific type, while the visible parent might be abstract or interface.

>> p2.ads:5:09: type must be declared abstract or "Foo" overridden
>> p2.ads:5:09: "Foo" has been inherited from subprogram at p1.ads:4
>> p2.ads:6:24: private function with tagged result must override 
>> visible-part function
>> p2.ads:6:24: move subprogram to the visible part (RM 3.9.3(10))
>>
>> [ Since when access types became tagged? ]
> 
> They're not "tagged", but they dispatch as if they were tagged (if 
> anonymous). So they have to follow the same rules as with a tagged type.

Then it should be said this way. I believe RM uses the word "controlling"
for this on other occasions.

>> There seem no way to implement T3 by deriving from T2. *Any* declaration 
>> of Foo would be illegal.
>>
>> 1. It cannot be inherited
>> 2. A public declaration is not an overriding
>> 3. A private declaration must be public
> 
> Right. The same would happen for the function Bar that I noted above.

Not exactly same, because for a tagged result the operation could be
inherited. For an access to tagged result it cannot be.

> But that just means that you can't hide T2.

Yep, that is the problem.

> There's no good reason to not 
> declare T3 as
>    type T3 is new T2 with private;
> and that eliminates any problem (you can then declare Foo anywhere you want 
> in the spec).

There are loads of good reasons to hide implementation details.

BTW, in the original code the type is declared unconstrained to prevent
unmanaged creation of objects. And the operation in question is not
intended to be used for the derived type.

> Anyway, it's definitely *not* a design bug. It follows from the requirement 
> that one can dispatch on the result; we can't allow dispatching to functions 
> that return the wrong kind of thing. 6.5(8.1/3) would require any attempt to 
> return the wrong kind of thing to raise Constraint_Error. That requires a 
> new body and automatically generating one that always raises 
> Constraint_Error would be madness. Thus the "shall be overridden" 
> requirement.

The function is not visible for public clients, they cannot call it.

> If there's a design bug, 
> it's the existence of anonymous access types at all with these unusual 
> special properties.

Maybe, but once introduced they should not break more important language
features, like information hiding.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de