!standard 13.1(9.1/1)                                          08-07-10  AI05-0106-1/02
!class binding interpretation 08-06-15
!status work item 08-07-08
!status received 06-06-21
!priority Low
!difficulty Easy
!qualifier Omission
!subject Representation items are not allowed on generic formal parameters
!summary

Representation items are not allowed on generic formal parameters.

!question

Consider:

   generic
      type T is new Some_Tagged with private;
      pragma Independent_Components (T);
   package G is ...

This appears to be legal, as 13.1(10) does not apply, and T is considered to be
a record type. But what does it mean? Does it put a restriction on the
actual types in an instance? (No, it is illegal.)

!recommendation

(See summary.)

!wording

Add after 13.1(9.1/1):

An operational or representational item shall not specify an aspect of a generic formal
parameter.

!discussion

However, the operational and representation aspects of a formal parameter are supposed to
come from the actual. It doesn't make sense to specify any of them on a formal parameter
(as opposed to a descendant of a formal parameter).

Most representation items are illegal on a formal type, as they require a first subtype
(and a generic formal type is not a first subtype). However, the pragmas in C.6 have
other requirements. Not all of them disallow formal types (specifically Volatile_Components,
which could be used on a formal array type or formal derived type that is an array, and
similarly for.

One possible fix would be to rewrite the resolution rules in C.6 to exclude formal types.
But this seems tricky and would make the resolution rules more specific than strictly
necessary (something we usually avoid).

Another approach would be to explicitly disallow representation pragmas from formal
parts. But this feels like an arbitrary rule. And it doesn't really solve the problem,
as the pragmas could still be given in the following package specification (neither the
formal part nor the package specification necessarily freeze the formal parameters).

We could also specify that generic formal parameters are always
considered to be frozen. This should be appropriate as their actual parameters will
always be frozen in any instance, as the instance freezes everything (by 13.14(5)).
However, that would potentially mean that dependent types (such as the parent type
of a formal derived type) would not get frozen when the formal type is frozen
for the first time. An alternative of freezing at the end of the formal part both
freezes too much and does so too late.

So, we ban all operational and representation items for generic formal parameters.
This was the approach used by Ada 83, but that was dropped for some unknown reason.
The rule is placed at the head of the specific legality rules for operational and
representation items as it is the broadest rule of the set.

Note that this rule is a bit broader than is needed to fix the problem. We could just
fix this for types (in which case modifying the last sentence of 13.1(11/2) might be
a better approach). But since the intent is that the properties generally come from
the actual parameters, it doesn't make much sense to allow specifying anything on
these. Do we want address clauses on formal objects or subprograms? Surely not.
The only thing that the author can think of that might remotely make sense is
specifying the size or alignment for an "in" formal object (a formal type would be
illegal as it is not a first subtype); but that seems like a rather bizarre thing
to do.

--!corrigendum 13.1(9.1/2)

!ACATS Test

An ACATS B-Test should be created to check that this is illegal. (Probably
just add cases to the existing tests.)

!appendix

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