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

--- ai05s/ai05-0106-1.txt	2008/07/09 00:06:51	1.1
+++ ai05s/ai05-0106-1.txt	2008/07/10 23:55:14	1.2
@@ -1,4 +1,4 @@
-!standard 13.14(3/1)                                          08-07-08  AI05-0106-1/01
+!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
@@ -29,31 +29,56 @@
 
 !wording
 
-Add after 13.14(3/1):
+Add after 13.1(9.1/1):
 
-A generic formal parameter is always considered frozen.
+An operational or representational item shall not specify an aspect of a generic formal
+parameter.
 
-AARM Ramification: This means that no operational or representation items are allowed on
-a generic formal type. But this does not freeze the profile of a generic formal subprogram
-or the index subtype of a formal array type.
-
 !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.
+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 unnecessary.
+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.
-
-Thus, we specify that generic formal types are always
-considered to be frozen (their actual type will always be frozen in any instance, as
-the instance freezes everything -- 13.14(5)).
+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.
+
+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.14(3/1)
+--!corrigendum 13.1(9.1/2)
 
 !ACATS Test