Re: Ada design bug or GNAT bug?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:56pbwdnfce0k$.5et1apcv65k9.dlg@40tude.net...
> On Fri, 3 Jul 2015 12:33:07 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>
>>> But even if you convert to the class-wide you don't get visibility of 
>>> the
>>> operation. In the scenario:
>>>
>>>   type T3 is new T1 with private;
>>> private
>>>   type T3 is new T2 with null record; -- Legal!
>>>
>>> a public client could not convert a T3 object to T2'Class. Could it?
>>
>> No, but a private client can, and if you have a public type T4 derived 
>> from
>> T3, it would not have the function operation.
>>
>> package P2 is
>>    type T3 is new T1 with private;
>>    procedure Do_It (X : inT3);
>> private
>>    type T3 is new T2 with null record; -- Legal!
>> end P2;
>>
>> with P2;
>> package P3 is
>>    type T4 is new P2.T3 with C : Character; end record; -- No defined F 
>> here.
>
> This must be illegal. The compiler shall require (unless T4 is abstract):
>
> 1. That the private part of the package had a full view of P2.T3
>
> 2. F overridden there.

But of course that breaks privacy: T4 knows nothing about the full type of 
T3 or any private operations it may have. If you mean that such a derivation 
should *always* be illegal, well, perhaps that would have been better, but 
its clearly too late (it has been legal for 20+ years, there's plenty of 
code that depends on deriving from a non-visible private type -- Claw has a 
number of such types [from sibling inheritance]).

>>> We have ugly executable precondition code at the declaration side. Why 
>>> not
>>> to allow this for functions?
>>
>> I don't understand what you mean. An expression function can be given as 
>> the
>> overriding, but that doesn't help if you don't have the needed visibility 
>> to
>> see the components in question (an aggregate is only legal if no private
>> types are involved -- we tried to find a way to relax that for Ada 2005, 
>> but
>> it just got way too messy).
>
> That is the idea, to do it without visibility. When you inherit bodies of
> procedures you don't need visibility. You "convert" parameters (view
> conversion, does nothing) and call the parent's body.
>
> Similarly we could compose a body of an invisible operation. In the 
> example
> above the invisible operation is F, when we derive T4 from T3 above. We do
> not need to know if F exists in order to say something like: if there is
> any primitive function returning T3 override it by adding 'A' for the
> component C. That would make
>
> package P3 is
>   type T4 is new T3 with record
>      C : Character;
>   end record
>      with overriding function C => 'A';
>          -- Imaginary syntax for automated function overriding aspect
>
> We could allow formal parameters of the aspect to be matched against
> parameters of overridden functions and used in the aggregate. We could
> allow a name of a body to initialize the type extension instead of an
> aggregate in order to move the mess into the package body instead of
> exposing it in the declaration scope, etc.

I had suggested something on this line (but simpler): simply flag if using 
the default values of the extension components are enough for constructing 
such values (they often will be). But it didn't get much traction.

You could of course submit something like the above to Ada-Comment. (Make 
sure to include a good problem description if you do; the problem is usually 
more important than the suggested solution.) At the least, it would add 
weight to the existing problem.

                              Randy.