!standard 13.1(8)                                         09-05-30  AI05-0112-1/03
!class binding interpretation 08-08-13
!status Amendment 201Z 09-02-21
!status WG9 Approved 09-06-12
!status ARG Approved  8-0-0  09-02-21
!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

Names are defined for aspects of representation that did not have them.

It is confirmed that if the Independent_Components aspect of
representation is specified for a tagged type, then that
aspect is inherited by derived types.

!question

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

!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):

  We give a default naming for representation aspects of representation
  pragmas so we don't have to do that for every pragma. A Volatile_Components
  pragma (see C.6), for example, specifies the Volatile_Components aspect
  of representation of its argument. Representation attributes are defined
  to be aspects of representation in 13.3. We don't want any anonymous
  aspects.

!discussion

Before attempting to answer the 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
      Nibble1 at 0 range 0 .. 3;
      Nibble2 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
      Nibble1 at 64 range 0 .. 3;
      Nibble2 at 64 range 4 .. 7;
   end record;

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

!comment !corrigendum 13.1(8)
!comment This wording is deleted by AI05-0295-1.

!comment @drepl
!comment A representation item @i<directly specifies> an @i<aspect of representation> of the
!comment entity denoted by the @fa<local_name>, except in the case of a type-related
!comment representation item, whose @fa<local_name> shall denote a first subtype, and which
!comment directly specifies an aspect of the subtype's type. A representation item that names
!comment a subtype is either @i<subtype-specific> (Size and Alignment clauses) or @i<type-related>
!comment (all others). Subtype-specific aspects may differ for different subtypes of the same type.
!comment @dby
!comment A representation item @i<directly specifies> an @i<aspect of representation> of the
!comment entity denoted by the @fa<local_name>, except in the case of a type-related
!comment representation item, whose @fa<local_name> shall denote a first subtype, and which
!comment directly specifies an aspect of the subtype's type. A representation item that names
!comment a subtype is either @i<subtype-specific> (Size and Alignment clauses) or @i<type-related>
!comment (all others). Subtype-specific aspects may differ for different subtypes of the same type.
!comment Unless otherwise specified, the name of the aspect of representation specified by a
!comment representation pragma is the name of the pragma. 

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

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