Re: Ada design bug or GNAT bug?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ykiyl6yc44or$.19365hv76bzoi.dlg@40tude.net...
> On Mon, 22 Jun 2015 12:39:16 -0500, Randy Brukardt wrote:
>
>> We don't have a choice about allowing hidden controlling results and
>> controlling access results (unless, of course, we want to abandon real
>> privacy, which we're not going to do).
>
> If function is invisible it is, and its result is as well.

Not really, because you can still dispatch to it (if the dispatching is 
somewhere that the private function is visible); dispatching does not 
respect privacy (as privacy is only a compile-time, not runtime, concept).

I realize that you hate redispatching (a point that I tend to agree with you 
on), but it's possible, and it's needed some part of the time (maybe 10% or 
even less, but more than 0%), so it exists and has to be taken into account.

>> The only way to avoid that problem is
>
> Which problem is? The operation is not visible, it cannot be called.

It surely can be called where it is visible, else it isn't very useful!

>> have the feature at all (which is where I would stand).
>
> I don't see connection to anonymous access types, the rule applies to
> tagged results as well:
>
> package P1 is
>   type T1 is tagged null record;
>   type T2 is new T1 with null record;
>   function Foo return T2;
> 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; -- Legal!

This is only legal because of a hack, which I was very much against 
introducing. If you have an extension component, this is illegal:

    type T4 is new T2 with record C : Character := '1'; end record; --  
Illegal!!!

> end P2;

I have tried to find a way to avoid this maintenance hazard (it's especially 
bad for mix-in generics), but I haven't gotten any traction to date. We 
could (if all of the extension components have defaults) automatically do 
this as we do for null record, but the problem is that making overriding 
required often detects bugs (failure to create a proper overriding). Plus 
the problem of incompatibility (only in obscure cases).

> 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 T3; -- ILLEGAL!
> end P2;
>
> As such the rule does not make any sense. You shall under no circumstance
> prohibit overriding of inherited operations.

That's only possible if you prohibit any extensions of T3. (Otherwise, you 
get the dispatching problems that I noted previously, or you have to break 
privacy by making the derived type illegal for something that is not 
visible.) We've talked a bit about having such an aspect, but it is messy.

To summarize: it's a bad interaction between privacy and things that require 
overriding (abstract subprograms follow the same rules for the same 
reasons). There's no real solution, else you could call abstract 
subprograms -- and then what??

                                          Randy.