Re: Ada design bug or GNAT bug?

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

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.

E.g.

package P2.P3 is
   type T4 is new T3 with record
      C : Character;
   end record;
private
   overriding function F (...) return T4;
end P2.P3;

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

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