!standard 13.1(8)                                         08-08-13  AI05-0112-1/01
!class binding interpretation 08-08-13
!status work item 08-08-13
!status received 08-06-21
!priority Low
!difficulty Easy
!qualifier Omission
!subject Names for anonymous aspects of representation

!summary

The aspect of representation specifed by a representation
pragma is never anonymous.

Confirmation: If the Independent_Components aspect of
representation is specfied for a tagged type, then that
aspect is inherited by derived types.

!recommendation

(See Summary.)

!wording

Append to the end of 13.1(8):
  Unless otherwise specified, the name of the aspect of
  representation specified by a representation pragma is
  the name of the pragma.

AARM note - append after 13.1(8):

  A Volatile_Components pragma (see C.6), for example, specifies the
  Volatile_Components aspect of representation of its argument.

!discussion

What is name of the aspect of representation specified by each of
the pragmas Atomic, Atomic_Components, Volatile, Volatile_Components,
Independent, and Independent_Components?

Before attempting to answer that question, consider why it is that
anyone would care about the answer. What difference does it make?

RM 13.1(9)states:
  If a representation item is given that directly specifies an aspect
  of an entity, then it is illegal to give another representation item
  that directly specifies the same aspect of the entity.

This clause is intended to prevent, for example, applying the same
representation pragma twice to a given type.

In a case such as

    type T is array (Character) of Float;
    pragma Pack (T);
    pragma Pack (T); -- illegal

the existing wording captures this intent because it is clear that the
Packing aspect has been specified twice.

In a case such as

    type T is array (Character) of Boolean;
    pragma Independent_Components (T);
    pragma Independent_Components (T); -- illegal?

the situation is not so clear. One might argue that the first
Independent_Components pragma certainly (wave hands here) specifies
*some* aspect of representation and that the second such pragma then
specifes the same aspect again.

This seems intuitive, but it does not seem to follow from a strict
reading of the existing wording.

Rather than trying to infer and/or invent rules about anonymous
aspects of representation, it seems simpler to give them names.

The existing wording (13.1(15/1)) about inheritance of aspects of
representation by derived types applies in both the tagged and the
untagged cases.

In particular, this applies to the Independent_Components aspect
of representation.

Assuming that a given implementation does not support independent
addressibility within an 8-bit storage unit, this implies that the
following examples must be rejected:

   type Untagged_Parent is
     record Nibble1, Nibble2 : Integer range 0 .. 15; end record;
   pragma Independent_Components (Untagged_Parent);

   type Untagged_Derived is new Untagged_Parent;

   for Untagged_Derived use record -- illegal
      F1 at 0 range 0 .. 3;
      F2 at 0 range 4 .. 7;
   end record;

   type Tagged_Parent is tagged null record;
   pragma Independent_Components (Tagged_Parent);

   type Tagged_Derived is new Tagged_Parent with
     record Nibble1, Nibble2
             : Integer range 0 .. 15; end record;

   for Tagged_Derived use record -- illegal
      F1 at 64 range 0 .. 3;
      F2 at 64 range 4 .. 7;
   end record;

Similarly, this wording also applies to the Volatile and
Atomic aspects of implementation.

--!corrigendum 13.1(8)

!ACATS Test

B-Tests for examples like these should be constructed.

!appendix

From the minutes of the Venice ARG meeting:

Steve wonders whether Independent is an aspect of representation. Tucker thinks
that is an interesting question that we haven't considered. C.6(14) says that
these are representation pragmas. But we don't have names for these aspects
of representation; there should be sentences about that (Atomic*, Volatile*,
Independent*). Tucker suggests a separate AI to answer this question.
Steve Baird has the short stick. Also, we should decide if all of these
are inherited for tagged types. Independent_Components applies to extension
components of a descendant (not to the parent components).
...

Ed suggests that he was previously wrong; we don't want inheritance for these
pragmas. Having that would prevent giving later representation clauses.

Steve Baird worries that type T is new S; would potentially be different from the
parent without inheritance.

We cannot decide on how or whether these pragmas are inherited; Steve is
directed to write up what makes sense to him and we'll throw stones at his
solution.

[Editor's note: version /01 is Steve's solution.]

****************************************************************