CVS difference for ai05s/ai05-0106-1.txt

--- ai05s/ai05-0106-1.txt	2008/10/25 04:53:14	1.4
+++ ai05s/ai05-0106-1.txt	2008/12/02 06:01:19	1.5
@@ -1,5 +1,7 @@
-!standard 13.1(9.1/1)                                          08-07-10  AI05-0106-1/02
+!standard 13.1(9.1/1)                                          08-11-20  AI05-0106-1/03
 !class binding interpretation 08-06-15
+!status Amendment 201Z 08-11-26
+!status ARG Approved  6-0-3  08-11-01
 !status work item 08-07-08
 !status received 06-06-21
 !priority Low
@@ -8,7 +10,8 @@
 !subject Representation items are not allowed on generic formal parameters
 !summary
 
-Representation items are not allowed on generic formal parameters.
+Operational and Representation items are not allowed on generic formal parameters
+unless they explicitly are allowed.
 
 !question
 
@@ -31,20 +34,27 @@
 
 Add after 13.1(9.1/1):
 
-An operational or representational item shall not specify an aspect of a generic formal
-parameter.
+Unless otherwise specified, an operational or representational item shall not specify
+an aspect of a generic formal parameter.
 
 !discussion
 
 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).
+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).
 
-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).
@@ -62,22 +72,33 @@
 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.
+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.
+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.
+
+!corrigendum 13.1(9.1/2)
+
+@dinsa
+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.
+@dinst
+Unless otherwise specified, an operational or representational item shall not specify
+an aspect of a generic formal parameter.
 
---!corrigendum 13.1(9.1/2)
 
 !ACATS Test