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

--- ai05s/ai05-0052-1.txt	2007/10/26 01:37:57	1.2
+++ ai05s/ai05-0052-1.txt	2008/02/05 02:46:56	1.3
@@ -1,4 +1,5 @@
-!standard 3.10.2(10.1/2)                            07-10-25    AI05-0052-1/02
+!standard 4.8(5.3/2)                               08-02-01    AI05-0052-1/03
+!standard 7.5(6.1/2)
 !class binding interpretation 07-05-15
 !status work item 07-05-15
 !status received 07-05-14
@@ -10,8 +11,11 @@
 !summary
 
 An allocator that is used to create a coextension is illegal if
-the designated type might be limited but the enclosing object might be
-of a nonlimited type.
+the designated type might be limited but the enclosing object is not
+inherently limited.
+
+The term "inherently limited type" is (re-)introduced to simplify the 
+presentation of this and other legality rules.
 
 !question
 
@@ -39,18 +43,35 @@
 
 If the designated type of the type of the allocator is limited, then
 the allocator shall not be used to define the discriminant of an
-object, unless the object is of a task, protected, or explicitly limited
-record type.
+object, unless the object is of an inherently limited type (see 7.5).
 
 AARM Note: Because coextensions work very much like parts, we don't want
-users creating limited coextensions for nonlimited types.  This would
-be similar to extending a nonlimited type with a limited component.  We
-check this on the allocator.  Note that there is an asymmetry in what
-types are considered limited; this is required to preserve privacy.  We
+users creating limited coextensions for nonlimited types. This would
+be similar to extending a nonlimited type with a limited component. We
+check this on the allocator. Note that there is an asymmetry in what
+types are considered limited; this is required to preserve privacy. We
 have to assume that the designated type might be limited as soon as we
 see a limited partial view, but we want to ensure that the containing
 object is of a truly limited type.
 
+Add after  7.5 (6.1/2):
+
+A type is inherently limited if it is one of the following:
+
+a) An explicitly limited record
+
+b) A tagged limited private type
+
+c) A task type, a protected type, or a synchronized interface.
+
+d) A type derived from an inherently limited type.
+
+AARM note: an inherently 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
+makes it inherently limited, then no assignment or copying operations
+are ever available for objects of the type, and it is safe for such objects
+to have access discriminants that designate other limited objects. 
+
 !discussion
 
 Consider the following example:
@@ -176,5 +197,31 @@
 As such, I don't see much point in adding a restriction here. But I realize that
 other implementations may have much more serious issues. Net-net: I can't endorse
 anything for this issue.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Monday, February 4, 2008  1:20 PM
+
+> [Is it time to define "inherently limited" in the RM?  I'd like to replace the
+> first two bullets with, "If the type of the newly-created object is inherently
+> limited, or has controlled parts, the anonymous object is built in place."
+> That's not quite the same thing -- it requires b-i-p in more cases than the
+> current RM.]
+
+Yes, this is AI-52, for which I sent an update on Saturday night.   
+Proposed definition:
+
+Add after  7.5 (6.1/2):
+
+A type is inherently limited if it is one of the following:
+
+a) An explicitly limited record
+
+b) A tagged limited private type
+
+c) A task type, a protected type, or a synchronized interface.
+
+d) A type derived from an inherently limited type.
 
 ****************************************************************