Re: Inheritance of representation aspects

[Simon Wright <simon@pushface.org>]

Adam Beneschan <adam@irvine.com> writes:

> On Sunday, February 3, 2013 8:27:20 AM UTC-8, Simon Wright wrote:
>> A question on Stack Overflow[1] asks about deriving from an unchecked
>> union. The questioner thinks that a derived type should also be
>> an unchecked union, but GNAT doesn't.
>> A demo is
>> 
>>    package Union is
>>       type Access_Kind is (Named, Indexed);
>>       type Array_Type is array (0 .. 1) of Integer;
>> 
>>       type Base (Kind : Access_Kind := Access_Kind'First) is record
>>          case Kind is
>>             when Named =>
>>                X, Y : Integer;
>>             when Indexed =>
>>                S : Array_Type;
>>          end case;
>>       end record with
>>         Unchecked_Union => True,
>>         Convention => C_Pass_By_Copy;
>> 
>>       --  A primitive operation, freezes Base.
>>       procedure P (R : Base) is null;
>> 
>>       --  Derived types should inherit both representation aspects, so
>>       --  both these aspects should be confirming 
>>       type Derived_1 is new Base with Unchecked_Union => True;
>>       type Derived_2 is new Base with Convention => C_Pass_By_Copy;
>> 
>>       --  This should fail (ARM 13.1(10)).
>>       type Derived_3 is new Base with Unchecked_Union => False;
>> 
>>    end Union;
>> 
>> Both Unchecked_Union and C_Pass_By_Copy are representation aspects, and
>> should therefore be inherited (I've given links at my SO answer[2]). So
>> the aspects specified for Derived_1 and Derived_2 should both be
>> confirming and therefore OK (?), while the aspect for Derived_3 should
>> be illegal by ARM 13.1(10).
>> 
>> With GNAT GPL 2012 and GCC 4.8.0 (r195682), Derived_1 and Derived_2 fail
>> (representation item appears too late) and Derived_3 doesn't raise an
>> error.
>> 
>> With GNAT GPL 2012, if I comment out Derived_1 and Derived_2, the
>> compilation is successful (with 4.8.0 I get a bug box, which is a
>> separate issue).
>> 
>> Am I correct that these aspects should be inherited?
>
> You're right that they should be inherited (13.1(15)), and that the
> declaration of Derived_3 would be illegal.
>
> I'm not clear that Derived_1 and Derived_2 are legal, however.  The
> aspect clauses are confirming, but there's no blanket rule that
> confirming aspect clauses are always legal.  The rule in 13.1(10) says
>
> "For an untagged derived type, it is illegal to specify a type-related
> representation aspect if the parent type is a by-reference type, or
> has any user-defined primitive subprograms."
>
> So it's illegal, period.  There is no exception here for confirming
> aspect clauses.

Still, it's be nice for it to be legal (perhaps 13.1(18.2) could be
amended to say that a confirming aspect clause isn't "really" a
specification?! Simpler if (10) just said that

  "For an untagged derived type, it is illegal to specify a
  *non-confirming* type-related representation aspect if the parent type
  is a by-reference type, or has any user-defined primitive
  subprograms."