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

--- ai05s/ai05-0067-1.txt	2008/02/05 04:27:59	1.2
+++ ai05s/ai05-0067-1.txt	2008/02/05 04:40:31	1.3
@@ -1,4 +1,4 @@
-!standard 7.5(8.1/2)                                         08-02-04    AI05-0067-1/02
+!standard 7.5(8.1/2)                                         08-02-04    AI05-0067-1/03
 !class binding interpretation 07-10-22
 !status work item 07-10-22
 !status received 07-09-03
@@ -114,21 +114,21 @@
 is "built in place", in which case the assignment need not involve
 any copying. In particular:
 
-    - If the type of the newly-created object has a part that is of a task,
-      protected, or explicitly limited record type, the anonymous object is
-      built in place.
+    - If the full type of the newly-created object is inherently limited,
+      the anonymous object is built in place.
 
     - In the case of an aggregate, if the type of the newly-created object is
       controlled, the anonymous object is built in place.
 
-    - In other cases, it is implementation dependent whether
-      the anonymous object is built in place.
+    - In other cases, it is unspecified whether the anonymous object is
+      built in place.
+
+["Inherently limited type" is defined in AI05-0052-1.]
+
+AARM Reason: We talk about the full type being inherently limited, as
+(like parameter passing), this is independent of the view of a type.
+That is, privacy is ignored for this purpose.
 
-[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.]
 
 Notwithstanding what this International Standard says elsewhere,
 if an object is built in place:
@@ -151,7 +151,7 @@
   same address as the newly-created object. Thus, no run-time action is
   required to cause all the access values and renamings to point to the right
   place. They just point to the newly-created object, which is what the return
-  object has magically "become".
+  object has magically "morphed into".
 
   There is no requirement that 'Address of the return object is equal to
   'Address of the newly-created object, but that will be true in this
@@ -162,10 +162,10 @@
   passed to the function; the return object is created at that address.
   Otherwise, a storage pool is implicitly passed to the function; the size is
   determined at the point of the return statement, and passed to the Allocate
-  procedure. The address returned by the thunk is returned from the function,
-  and the newly-created object uses that same address. If the return statement
-  is left without returning (via an exception or a goto, for example), then
-  Deallocate is called.
+  procedure. The address returned by the storage pool is returned from the
+  function, and the newly-created object uses that same address. If the
+  return statement is left without returning (via an exception or a goto,
+  for example), then Deallocate is called.
 
   The Tag of the newly-created object may be different from that of the result
   object. Likewise, the master and accessibility level may be different.