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

Differences between 1.9 and version 1.10
Log of other versions for file ai05s/ai05-0052-1.txt

--- ai05s/ai05-0052-1.txt	2008/05/24 03:39:52	1.9
+++ ai05s/ai05-0052-1.txt	2008/05/29 01:52:49	1.10
@@ -1,4 +1,4 @@
-!standard 4.8(5.3/2)                                  08-05-23    AI05-0052-1/08
+!standard 4.8(5.3/2)                                  08-05-28    AI05-0052-1/09
 !standard 7.5(8)
 !class binding interpretation 07-05-15
 !status ARG Approved  7-0-1  08-02-09
@@ -139,7 +139,7 @@
 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
+region of a generic unit, if the formal type is declared within the
 formal part of the generic unit.
 
 AARM Ramification: In an instance, a type is descended from the actual type
@@ -321,7 +321,8 @@
 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.
+if the formal type is declared within the formal part of the generic
+unit.
 
 
 !ACATS test
@@ -925,4 +926,97 @@
 Pascal has forced us to withdraw various AIs anyway, we might as well stick
 the repair in AI-52. In which case I guess I can do your work for you.
 
-****************************************************************
\ No newline at end of file
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, May 28, 2008  12:05 AM
+
+Incidentally, I am a bit annoyed by the difference in terminology
+between "immutably limited type" and "explicitly limited record type".
+It would have been nice to use the same adverb somehow. But I suppose
+that you guys have discussed this ad nauseum...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, May 28, 2008  12:09 AM
+
+We did get pretty nauseated during the discussion, if I remember
+correctly.  Perhaps "nauseatingly limited" might have been a better
+term... ;-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, May 28, 2008  12:19 AM
+
+Perhaps with the slight tweak in the definition that you suggested,
+by eliminating the dependence on "parts," we might be able to go to
+something like "explicitly limited type," where "explicitly limited
+record" is an obvious special case.  Might deserve some thought.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Wednesday, May 28, 2008  12:30 AM
+
+That crossed my mind too.  To some extent that terminology would work
+better for formal types.  It seems to me that they are "explicitly limited"
+('cause I can see the word "limited" there) but not "immutably limited"
+('cause they can become unlimited in an instance).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, May 28, 2008  2:59 PM
+
+But I would expect that calling task types, protected types, and
+synchronized interfaces "explicitly limited" would offend your
+French sensibilities. :-) No word "limited" to be seen in any of those.
+Moreover, limited private types and limited interfaces would not be
+"explicitly limited" even with the presence of the word "limited".
+That seems too confusing to contemplate.
+
+So I think is best to leave this sleeping dog lie. Especially as Tucker's
+"presumed to be immutably limited" wording eliminates the discomfort on
+formal types (and is more like other wording as well, seems like a win-win).
+
+Just a reminder, here's the current wording for "immutably limited":
+
+A type is *immutably limited* if it is one of the following:
+
+    *  An explicitly limited record type;
+
+    *  A non-formal limited private type that is tagged or has
+       at least one access discriminant with a default_expression;
+
+    *  A task type, a protected type, or a synchronized
+       interface;
+
+    *  A descendant of an immutably limited type.
+
+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.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, May 28, 2008  3:32 PM
+
+I would suggest one tweak to the wording below:
+
+...
+> 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 
+> {*formal*} type is declared within the
+                                     ^^^^^^^^
+> formal part of the generic unit.
+
+I think it is important to say the *formal* type since otherwise
+we have an ambiguity as to whether we are talking about the "descendant"
+or the "generic formal limited private type."
+
+****************************************************************

Questions? Ask the ACAA Technical Agent