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

--- ai05s/ai05-0067-1.txt	2008/07/11 03:52:12	1.9
+++ ai05s/ai05-0067-1.txt	2008/11/18 05:45:26	1.10
@@ -1,4 +1,4 @@
-!standard 4.3.2(5/2)                                         08-07-10    AI05-0067-1/06
+!standard 4.3.2(5/2)                                         08-11-17    AI05-0067-1/07
 !standard 7.5(8.1/2)
 !standard 7.5(9/2)
 !standard 7.6(0)
@@ -8,6 +8,7 @@
 !standard 7.6(18)
 !standard 7.6(21/2)
 !class binding interpretation 07-10-22
+!status ARG Approved  6-0-1  08-11-02
 !status work item 07-10-22
 !status received 07-09-03
 !priority High
@@ -60,9 +61,9 @@
 
 !wording
 
-3.9.1(8.a):  After first sentence, add "It also makes it easier to implement
-extension aggregates in the case where the type is limited, the object is
-allocated from a user-defined storage pool, and the discriminants are
+Add to AARM note: 3.9.1(8.a):  After first sentence, add "It also makes it easier
+to implement extension aggregates in the case where the type is limited, the
+object is allocated from a user-defined storage pool, and the discriminants are
 inherited from the parent type."
 
 Add after 4.3.2(5/2):
@@ -77,12 +78,14 @@
 callee would have to be combined to determine the appropriate size.
 
 The (F(...) with null record) case is exempt from this rule, because
-(1) it is not needed in that case, and (2) such extension aggregates
-are created internally for inherited functions returning null-extension
-types -- we can't very well make those illegal.
+such extension aggregates are created internally for inherited functions
+returning null-extension types -- we can't very well make those illegal.
+Moreover, we don't need the rule for null extensions, as the result can
+simply use the space returned by the function call.
 [end AARM Reason]
 
-Remove 7.5(8.1/2), which is an "Implementation Requirements".
+Remove 7.5(8.1/2), which is an "Implementation Requirements". Move the
+AARM note as noted below.
 
 Add "(see 7.6)" to the end of 7.5(9/2).
 
@@ -98,8 +101,9 @@
 
 When a function call or aggregate is used to initialize an object, the
 result of the function call or aggregate is an anonymous object, which
-is assigned into the newly-created object.
-Under certain circumstances, the anonymous object is "built in place",
+is assigned into the newly-created object. For such an assignment,
+the anonymous object might be built in place. Under certain circumstances,
+the anonymous object is required to be "built in place",
 in which case the assignment does not involve any copying. In particular:
 
     - If the full type of any part of the object is immutably limited,
@@ -112,9 +116,9 @@
     - In other cases, it is unspecified whether the anonymous object is
       built in place.
 
-["Immutably limited type" is defined in AI05-0052-1.]
+["Immutably limited type" is defined in AI05-0052-1 - ED]
 
-AARM To Be Honest: We say assignment to built-in-place objects does not
+AARM Discussion: We say assignment to built-in-place objects does not
 involve copying, which matches the intended implementation (see below).
 Of course, the implementation can do any copying it likes, if it can make
 such copying semantically invisible (by patching up access values to point
@@ -124,9 +128,11 @@
 parameter passing), this is independent of the view of a type.
 That is, privacy is ignored for this purpose.
 
+[Place existing AARM notes 7.6(17.h.1-17.i/2) here.]
+
 AARM Discussion: For function calls, we only require building in place for
 immutable types. These are the types that would have been return-by-reference
-types in Ada 95.We do this because we want to minimize disruption to Ada 95
+types in Ada 95. We do this because we want to minimize disruption to Ada 95
 implementations and users. [This note was 7.5(8.e/2) - ED]
 
 Notwithstanding what this International Standard says elsewhere, if an object
@@ -150,7 +156,7 @@
     - Coextensions of the anonymous object become coextensions of the
       newly-created object.
 
-AARM notes:
+AARM Implementation Notes:
 
   The intended implementation is that the anonymous object is allocated at the
   same address as the newly-created object. Thus, no run-time action is
@@ -159,7 +165,7 @@
   object has magically "mutated 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
+  'Address of the newly-created object, but that will be true in the intended
   implementation.
 
   For a function call, if the size of the newly-created object is known at the
@@ -191,8 +197,8 @@
 Likewise, if some other task accesses the tag field during this modification,
 it constitutes improper use of shared variables, and is erroneous.
 
-Remove 7.6(17.1/2), which is an "Implementation Requirements". Put the AARM
-notes 7.6(17.h.1-17.i/2) in the group of AARM notes before "Notwithstanding".
+Remove 7.6(17.1/2), which is an "Implementation Requirements". Move the AARM
+notes 7.6(17.h.1-17.i/2) as noted above.
 
 Delete "nonlimited" from 7.6(18).
 
@@ -383,8 +389,9 @@
 @dinss
 When a function call or @fa<aggregate> is used to initialize an object, the
 result of the function call or @fa<aggregate> is an anonymous object, which
-is assigned into the newly-created object.
-Under certain circumstances, the anonymous object is @i<built in place>,
+is assigned into the newly-created object. For such an assignment, the
+anonymous object might be built in place.
+Under certain circumstances, the anonymous object is required to be @i<built in place>,
 in which case the assignment does not involve any copying. In particular:
 
 @xbullet<If the full type of any part of the object is immutably limited,
@@ -467,8 +474,9 @@
 !ACATS Test
 
 This just clarifies the rules, so that additional tests are not needed. However,
-it could change the semantics of a few existing tests. Also, there may be value
-to testing an example using extension aggregates.
+it could change the semantics of a few existing tests.
+
+But, the new legality rule for extension aggregates should be tested with a B-Test.
 
 !appendix