Inheritance of representation aspects

Inheritance of representation aspects

[Simon Wright]

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?

[1]
http://stackoverflow.com/questions/14663316/derive-from-unchecked-union
[2]
http://stackoverflow.com/questions/14663316/derive-from-unchecked-union/14671548#14671548

Re: Inheritance of representation aspects

[Adam Beneschan]

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.

                            -- Adam

Re: Inheritance of representation aspects

[Simon Wright]

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

Re: Inheritance of representation aspects

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyehgwrl96.fsf@pushface.org...
...
> 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."

Since 13.1(10) long predates the notion of "confirming" rep. clause, it 
doesn't surprise me. Personally, I'd much prefer if this rule didn't exist 
(although it does eliminate some weird cases that we'd otherwise have to 
deal with). It makes it virtually impossible to use an untagged derived type 
for anything valuable (no representation changes unless there are no 
operations -- in which case what is the point of supporting a representation 
change). I've never gotten any traction on that, and I doubt that I ever 
will, so mainly I think, forget about untagged derived types as a useless 
appendage of the language. (It's not worth fixing this rule, as it still 
won't allow anything useful other than silly test programs.)

                                    Randy.