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

Representation and operational items are not allowed on generic formal parameters unless they are explicitly allowed.

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

Unless otherwise specified, an operational or representation 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. If they are specified for a formal parameter, that implies an added contract to the generic. Such added contracts have to be described for each aspect (since aspects may be values or properties).

For the language-defined aspects, we did not identify any for which the effort of defining generic matching rules to enforce the added contract provided a valuable capability. As such, we don't want any of the language-defined aspects to be be defined for a formal parameter.

Most operational and 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 we allow an item to be explicitly allowed on a generic formal parameter. We allow this exception for possible future pragmas and implementation-defined pragmas. Hopefully, the need to mention the exception will make visible to the definer of such an item the need to provide generic matching rules.

Note that this rule is a bit broader than is needed to fix the problem of the question. 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 formal parameters. Do we want address clauses on formal objects or subprograms? Surely not.

An operational item that directly specifies an aspect of a type shall appear before the type is frozen (see 13.14). If an operational item is given that directly specifies an aspect of a type, then it is illegal to give another operational item that directly specifies the same aspect of the type.

Unless otherwise specified, an operational or representation item shall not specify an aspect of a generic formal parameter.

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

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