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

--- ai05s/ai05-0052-1.txt	2008/03/07 06:15:19	1.6
+++ ai05s/ai05-0052-1.txt	2008/05/10 05:14:33	1.7
@@ -1,5 +1,5 @@
-!standard 4.8(5.3/2)                               08-02-24    AI05-0052-1/05
-!standard 7.5(8/2)
+!standard 4.8(5.3/2)                               08-04-09    AI05-0052-1/06
+!standard 7.5(8)
 !class binding interpretation 07-05-15
 !status ARG Approved  7-0-1  08-02-09
 !status work item 07-05-15
@@ -35,7 +35,7 @@
 This expense is incurred even if the program never allocates any
 such coextension.
 
-Was this intended?
+Was this intended? (No.)
 
 Second, in an apparently unrelated topic:
 
@@ -75,7 +75,8 @@
 With the current wording of the Standard, it appears that the instance
 would be illegal if X were in the visible part of Gen_Pack; but with X
 in the private part, the program is legal but will raise an exception
-at runtime. There doesn't seem to be a good reason for this difference.
+at runtime. There doesn't seem to be a good reason for this difference,
+is it intentional? (No.)
 
 !recommendation
 
@@ -111,7 +112,7 @@
 normally apply (see 12.3), these rules apply also in the private part
 of an instance of a generic unit.}
 
-Add after 7.5 (8/2):
+Add after 7.5 (8):
 
 A type is *immutably limited* if it is one of the following:
 
@@ -135,7 +136,7 @@
 have defaults or designate other limited objects. 
 
 AARM Ramification: A limited interface is not immutably limited; a type derived
-from it can be non-limited.
+from it can be nonlimited.
 
 !discussion
 
@@ -228,7 +229,15 @@
 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.
 
+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
+always limited in any view, that these rules were complicated (and wrong in a
+number of instances), and thus it was determined that defining a term to
+increase the commonality of those rules was a good idea. "Immutably" was chosen
+after an intermably long discussion as the best choice of literally dozens that
+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.
 
@@ -242,7 +251,7 @@
 an allocator).
 
 So, we factor out the "applies in the private part of an instance" wording into
-a separate pargraph that applies to all of the legality rules of 4.8.
+a separate paragraph that applies to all of the legality rules of 4.8.
 
 
 !corrigendum 4.8(5.3/2)
@@ -273,7 +282,7 @@
 of an instance of a generic unit.
 
 
-!corrigendum 7.5(8/2)
+!corrigendum 7.5(8)
 
 @dinsa
 There are no predefined equality operators for a limited type.