Version 1.4 of ai05s/ai05-0106-1.txt

Representation items are not allowed on generic formal parameters.

Consider:

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

Add after 13.1(9.1/1):

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

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

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)

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

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