Re: Ada design bug or GNAT bug?

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

"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. :-)

Since you did use an anonymous access result, you have a function with a 
"controlling access result". This works much like
   function Bar return T2;
which has a "controlling result".

If you had used a named access type, you definitely would not have this 
problem - 3.9.3(10/3) only applies to anonymous access types.

> end P1;
>
> with P1; use P1;
> package P2 is
>   type T3 is new T1 with private;
> private
>   type T3 is new T2 with null record;
>   overriding function Foo return not null access T3; -- Illegal!
> end P2;
>
> 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.

> 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.

But that just means that you can't hide T2. 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).

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.

Perhaps you didn't want to dispatch on the result, but too bad, that's how 
anonymous access designated tagged types is defined (it's supposed to be an 
exact equivalent of anonymous access parameters). If there's a design bug, 
it's the existence of anonymous access types at all with these unusual 
special properties.

Anyway, there are three workarounds: (1) don't hide T2; (2) use a named 
access type; (3) use a class-wide type for the return (thus turning off 
dispatching).

                            Randy.