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

--- ai05s/ai05-0052-1.txt	2008/05/10 05:14:33	1.7
+++ ai05s/ai05-0052-1.txt	2008/05/22 05:22:45	1.8
@@ -1,4 +1,4 @@
-!standard 4.8(5.3/2)                               08-04-09    AI05-0052-1/06
+!standard 4.8(5.3/2)                               08-05-21    AI05-0052-1/07
 !standard 7.5(8)
 !class binding interpretation 07-05-15
 !status ARG Approved  7-0-1  08-02-09
@@ -88,9 +88,9 @@
 
 An allocator shall not be of an access type for which the Storage_Size
 has been specified by a static expression with value zero or is defined
-by the language to be zero. In addition to the places where Legality Rules
+by the language to be zero. [In addition to the places where Legality Rules
 normally apply (see 12.3), this rule applies also in the private part of
-an instance of a generic unit. This rule does not apply in the body of
+an instance of a generic unit.] This rule does not apply in the body of
 a generic unit or within a body declared within the declarative region
 of a generic unit, if the type of the allocator is a descendant of a
 formal access type declared within the formal part of the generic unit.
@@ -116,17 +116,14 @@
 
 A type is *immutably limited* if it is one of the following:
 
-*  A descendant of an explicitly limited record type;
+    *  An explicitly limited record type;
 
-*  A descendant of a non-formal tagged limited private type;
+    *  A non-formal tagged limited private type;
 
-*  A descendant of a task type, a protected type, or a synchronized interface;
+    *  A task type, a protected type, or a synchronized
+       interface;
 
-*  A descendant of a formal limited private type, except within the body of a generic unit
-   or a body declared within the declarative region of a generic unit, if the type is
-   declared within the formal part of the generic unit;
-
-*  A type with a part that is of an immutably limited type.
+    *  A descendant of an immutably limited type.
 
 AARM Discussion: An immutably limited type is a type that cannot become nonlimited
 subsequently in a private part or in a child unit. If a view of the type
@@ -138,6 +135,17 @@
 AARM Ramification: A limited interface is not immutably limited; a type derived
 from it can be nonlimited.
 
+A descendant of a generic formal limited private type is
+presumed to be immutably limited except within the body
+of a generic unit or a body declared within the declarative
+region of a generic unit, if the type is declared within the
+formal part of the generic unit.
+
+AARM Ramification: In an instance, a type is descended from the actual type
+corresponding to the formal, and all rules are rechecked. Bodies are
+excepted so that we assume the worst there; the complex wording is
+required to handle children of generics and unrelated bodies properly.
+
 !discussion
 
 Consider the following example:
@@ -226,8 +234,10 @@
 
 Note that this rule in incompatible with Ada 95 in unusual cases; those
 where a coextension is created with a limited type (including limited private types)
-and the type with the discriminant is not known to be limited (usually a limited
-private type.) Coextension use is rare enough that this is not that important.
+and the type with the discriminant is not known to be limited (a limited
+private type, the only case where an access discriminant is allowed on
+something that Ada 2005 could complete with a non-immutably limited type).
+Coextension use is rare enough that this is not that important.
 
 As part of this rule, we have defined the term "immutably limited". We noticed
 at a recent meeting that we had a number of rules related to types that are
@@ -238,8 +248,8 @@
 were proposed.
 
 
-For the second question, we note that would need to check the new rule in the
-private part of an instance, and 4.8(5.3/2) already has such a rule.
+For the second question, we note that the new rule would need to be checked in the
+private part of an instance, and 4.8(5.3/2) already has such wording.
 
 The example in the question makes it clear that 4.8(5.1/2) also should be checked
 in the private part. There doesn't seem to be any benefit in postponing detection
@@ -559,5 +569,249 @@
 
 Precisely, that is not inherently limited, and thus cannot have an  
 access discriminant whose designated type is limited.
+
+****************************************************************
+
+Summary of editorial review discussion (May 2008):
+
+Pascal Leroy:
+I didn't study AI 52 very carefully, but I think it's disgggusting to
+include formal types in "immutably limited" types. First, you are
+lying about the work "immutably", and that makes any usage of term
+confusing. It would be much better to say "immutably limited or descended
+from a formal limited private type" when needed.  
+ 
+Randy Brukardt:
+This doesn't work, because of the body exception. It would have to be
+"immutably limited or descended from a formal limited private type other
+than in a generic body or a body nested in that body if the type is
+declared in the specification of the body", and that would defeat the
+entire purpose. It would get forgotten or done incorrectly - that was
+the reason for introducing the term in the first place. We tried to
+figure a name for this concept for a LONG time, and this is what we
+came up with.
+
+Pascal Leroy:
+Well, I don't imagine how anyone would think of sending AI 52 to WG9
+without any wording in this AI that tries to show how the term
+"immutably limited" could be used in the rest of the RM.  The only
+indication that this was even considered is a note in the minutes
+that says: Steve Baird has volunteered himself to investigate what
+other rules in the Standard could (and perhaps should) use "immutably
+limited". There is not much point in defining this term if it is used
+only once.
+
+Randy Brukardt:
+For the record, the term is also used in AI-54-2 and AI-59 (both
+still open), AI-93 (that's Steve's homework, it just adds it in the
+definition of "known to be constrained" from AI05-0008-1) and AI-53
+(also going to WG9). The point is that we *did* consider how it was
+going to be used in a large number of places, perhaps just not carefully
+enough.
+ 
+One could argue that the existence of so many places with slightly
+different rules shows an existing language bug more than a feature.
+
+Pascal Leroy:
+Now you are going to tell me that it's also used in AI 63. But that's
+exactly what worries me, because this AI causes is a significant
+semantic: previously, a defaulted access discriminant was only
+allowed by 3.7(10/2) in the cases that correspond to bullets 1, 2,
+and 3 of the definition of "immutably limited". But now bullets 4
+and 5 taken together make more cases legal. Consider:
+ 
+generic
+   type T is limited private;
+package G is
+   type R(D : access Integer := new Integer'(9)) is
+      record
+         X : T
+      end record;
+end G;
+ 
+According to AI 52 type T is immutably limited in the generic
+specification (bullet 4) and so is type R (bullet 5).  According to
+AI 63, the defaulted access discriminant is legal.  This is very
+strange: this generic was illegal in Ada 2005, but it is legal in
+TC2. However, it cannot be instantiated with a nonlimited type
+(instantiation rechecking will ensure this). What good does that do?
+Ada is about detecting errors early, not about telling you on
+instantiations that sorry, you cannot use this generic that way
+(says someone who uses C++ templates daily). There is no indication
+in the minutes or in the AI that this change was intended.
+ 
+Incidentally, you'd have the same problem if you tried to use
+"immutably limited" in the current instance rule in 3.10(9/2).
+
+Randy Brukardt:
+We did, in AI05-0053-1, which you didn't reach in your review.
+ 
+Tucker Taft:
+I agree the term "immutably limited" is somewhat problematic when
+associated with formal limited types. Perhaps we simply need to
+say that a formal limited type is *presumed* to be immutably limited
+in the generic spec (but rechecked in the instance), rather than
+saying that it *is* immutably limited. In the body, it is *not*
+considered immutably limited if an actual type might not be immutably
+limited.
+
+Hence, with a relatively minor wording fix we could preserve the
+generality of the term, but avoid misleading users into thinking that
+formal limited types *require* that the actual be immutably limited,
+unless there is a use in the spec that requires that.
+
+Possible fix to wording:
+
+  A type is *immutably limited* if it is one of the following:
+
+  *  A descendant of an explicitly limited record type;
+
+  *  A descendant of a non-formal tagged limited private type;
+
+  *  A descendant of a task type, a protected type, or a synchronized interface;
+
+  *  A type with a part that is of an immutably limited type.
+
+  Within the declaration of a generic unit having a
+  parameter that is a formal limited private type, any
+  descendant of the formal type is presumed to be
+  immutably limited.  Any legality rule that requires
+  a type be immutably limited also applies in the
+  private part of a generic instance.
+
+-----------
+
+I realize this wording is a bit unorthodox. Perhaps it can be rephrased
+to be more consistent with other similar situations.
+
+Pascal Leroy:
+
+This doesn't address my point that AI 52+63 makes some constructs legal
+in TC2 that were illegal in Ada 2005. There is no indication in any
+document that I have read that says that it was intended. In particular,
+I draw your attention to 3.7(10.e/2) which makes it very clear that the
+designers of Ada 95, in their infinite wisdom, decided that a type with
+an immutably limited component was not itself immutably limited (and I
+think they were right then, and wrong now).
+
+Tucker Taft:
+
+Sorry, I hadn't understood your point. Now I see and I agree there is
+no need to give special "immutably limited" status to types that get
+limitedness from their subcomponents.
+
+So we could eliminate the fourth bullet.
+
+At that point we might be able to eliminate the repetitive use of
+"descendant" and move that to its own bullet. I remember we couldn't
+factor out the descendant part originally for some reason, perhaps
+because we were trying to factor out the "part" part.  Hence, this
+would produce:
+
+    A type is *immutably limited* if it is one of the following:
+
+    *  An explicitly limited record type;
+
+    *  A non-formal tagged limited private type;
+
+    *  A task type, a protected type, or a synchronized
+       interface;
+
+    *  A descendant of an immutably limited type.
+
+    Within the declaration of a generic unit having a
+    parameter that is a formal limited private type, any
+    descendant of the formal type is presumed to be
+    immutably limited.  Any legality rule that requires
+    a type be immutably limited also applies in the
+    private part of a generic instance.
+
+Randy Brukardt:
+
+> Sorry, I hadn't understood your point. Now I see and I agree there is 
+> no need to give special "immutably limited" status to types that get 
+> limitedness from their subcomponents.
+
+You probably were confused probably because it was quite different
+that the original issue that Pascal raised. I think he originally
+pointed at the wrong culprit, and that confused all of us initially.
+
+I recall being unconfortable with the inclusion of "part" here, but
+mainly because it made Is_Immutably_Limited change depending on the
+view of the components, which seemed like it opened up the door for
+anomolies. I tried to raise the point during the discussion in Florida,
+but the conversation went in a different direction and I got too
+engrossed in keeping minutes to persue it.
+
+...
+>     Within the declaration of a generic unit having a
+>     parameter that is a formal limited private type, any
+>     descendant of the formal type is presumed to be
+>     immutably limited.  Any legality rule that requires
+>     a type be immutably limited also applies in the
+>     private part of a generic instance.
+
+This last paragraph doesn't work right. It's missing the generic body
+exception, for one thing. It should only be presumed to be immutably
+limited in the specification of a generic unit, not in the body; and it
+needs to take children into account. And the last part doesn't come
+close to the normal boilerplate. Moreover, I don't think it is needed;
+the rules already require that or it doesn't matter. And this isn't
+always used in Legality Rules: 3.10(9/2) is static semantics, as is the
+definition of "known to be constrained". So I suggest replacing the last
+paragraph with:
+
+    A descendant of a generic formal limited private type is
+    presumed to be immutably limited except within the body
+    of a generic unit or a body declared within the declarative
+    region of a generic unit, if the type is declared within the
+    formal part of the generic unit.
+
+(We know that this last wording is the in the right order for generic bodies,
+because we use variants of it in a number of other rules; inventing new wording
+is likely to be error-prone, especially for cases this complex.)
+
+-----------
+
+The interesting question is whether any of the new rules (specifically the ones
+in AI-52 and AI-08) need to include "parts" of an immutably limited type. (I
+presume the existing rules got it right, so they shouldn't use "part", as noted
+by Pascal.)
+
+For AI-52, the operative part is:
+
+If the designated type of the type of the allocator is limited, then the
+allocator shall not be used to define the value of an access discriminant,
+unless the discriminated type is immutably limited (see 7.5).
+
+This seems to nicely echo the wording of 3.7(10/3), so it would be weird to
+allow more here. Moreover, there isn't a compatibility concern with Ada 95:
+the only access discriminants are for immutably limited types, so this rule
+always would pass.
+
+However, there's a problem: 3.7(10) allows access discriminants in private
+types so long as the full type is immutably limited; that got lost in
+Ada 2005's 3.7(10/2), and 3.7(10/3) just copies that. Tucker has an action item
+to see if that needs a fix. Not sure whether that fix needs to be in the
+definition of immutably limited or just in 3.7(10/3). If just 3.7(10/3) is
+changed, then there is a possibility of an Ada 95 incompatibility -- but that
+wouldn't be fixed by including parts anyway.
+
+So, pending resolution of that issue, there doesn't seem to be any reason to
+change this rule to include parts. Ada 95 didn't allow them, so there is
+unlikely to be an issue.
+
+For AI-08 (as updated by Steve's AI-93), the third bullet would be:
+
+its type is immutably limited (see 7.5); or
+
+Here, I don't think we want this changing when views of components change,
+so I don't think it either should be changed. And parts were not included
+in the original rule. Formal types will always be rechecked, so they can't
+introduce any holes.
+
+So I think that we're OK here.
+
+I've updated the AI with these changes (excepting Tucker's action item).
 
 ****************************************************************