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

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0067-1.txt

--- ai05s/ai05-0067-1.txt	2008/02/05 06:33:09	1.4
+++ ai05s/ai05-0067-1.txt	2008/02/22 01:10:26	1.5
@@ -1,4 +1,4 @@
-!standard 7.5(8.1/2)                                         08-02-04    AI05-0067-1/03
+!standard 7.5(8.1/2)                                         08-02-21    AI05-0067-1/04
 !class binding interpretation 07-10-22
 !status work item 07-10-22
 !status received 07-09-03
@@ -98,6 +98,10 @@
 supposed to create an anonymous object, it doesn't say what will
 replace the anonymous object where that matters. What is the intent?
 
+(3) The assignment operation is defined for all types in the Amendment. But 7.6(16)
+and 7.6(18) have parenthetical remarks suggesting that they apply only to nonlimited
+types. Should that be corrected? (Yes.)
+
 !recommendation
 
 (See Summary.)
@@ -188,6 +192,15 @@
 or via dispatching). I think should raise Program_Error. (Premature means
 before the return statement is done.) Any sympathy for that?
 
+Previously in AI05-0004-1:
+
+(3) The first sentence of 7.6(16) should be modified:
+  To adjust the value of a [(nonlimited)] composite object, the values of the components
+  of the object are first adjusted in an arbitrary order, and then, if the object is
+  {nonlimited} controlled, Adjust is called.
+
+"nonlimited" should be deleted from 7.6(18).
+
 !discussion
 
 Consider the following example. We have an allocator with a limited heap
@@ -274,8 +287,42 @@
 two objects' Tags are at the same address.
 
 
+[Previously in AI05-0004-1.]
+(3) These two paragraphs apply to all types, and surely should not claim to not apply
+to nonlimited types only. The implementation permission of 7.6(17.1/2) depends on 7.6(21/2),
+a rule which is under the header of 7.6(18): we better include limited types in 7.6(18).
+
+In addition, 7.6(16) should say that Adjust is called only for nonlimited controlled types,
+so that the canonical semantics (before the build-in-place requirement of 7.6(17.1/2)
+is applied) is well-defined.
+
+
 --!corrigendum 7.6.1(17.1/1)
 
+!corrigendum 7.6(16)
+
+@drepl
+To adjust the value of a (nonlimited) composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object
+is controlled, Adjust is called. Adjusting the value of an elementary
+object has no effect, nor does adjusting the value of a composite object with no
+controlled parts.
+@dby
+To adjust the value of a composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object
+is nonlimited controlled, Adjust is called. Adjusting the value of an elementary
+object has no effect, nor does adjusting the value of a composite object with no
+controlled parts.
+
+!corrigendum 7.6(18)
+
+@drepl
+An implementation is allowed to relax the above rules (for nonlimited controlled
+types) in the following ways: 
+@dby
+An implementation is allowed to relax the above rules (for controlled types) in
+the following ways: 
+
 !ACATS Test
 
 ** TBD **
@@ -707,7 +754,7 @@
 ****************************************************************
 
 From: Tucker Taft
-Sent: Tuesday, August 7, 2007  x:xx PM
+Sent: Tuesday, August 14, 2007  8:08 AM
 
 ... As far as your question about an ancestor part
 that is specified by an abstract ancestor
@@ -739,6 +786,54 @@
 whose type is that of the ancestor part.  I.e., it is roughly
 equivalent to 'Access applied to a view conversion, e.g.
 T2(New_Obj_Of_Type_T3)'Access.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, August 24, 2007  10:38 PM
+
+Not wanting to do anything tough, I'm working on test objectives for 7.6 this evening
+before leaving. I noticed a very minor glitch in 7.6(16) and 7.6(18).
+
+7.6(13-15) talks about the canonical implementation of the assignment operation. That
+is now defined for limited types. 7.6(16) defines adjustment for, including a call to
+Adjust. The paragraph parenthetically claims to apply only to non-limited types, but that
+begs the question of what the meaning of this is for limited types. (Yes, I know that
+later requirements are intended to make this moot, but should the canonical semantics
+really be undefined??)
+
+So I suggest removing the parenthetical non-limited, and adding a word to make it clear
+that adjusting a limited type is a no-op (and surely does not call a routine that does
+not exist!):
+
+"To adjust the value of a [(nonlimited)] composite object, the values of the components
+of the object are first adjusted in an arbitrary order, and then, if the object is
+{nonlimited} controlled, Adjust is called. Adjusting the value of an elementary object
+has no effect, nor does adjusting the value of a composite object with no controlled parts."
+
+We could add something to the last phrase about limited objects, but since it is already
+considered redundant, it isn't necessary (and might be considered conflicting with the
+requirements following).
+
+The AARM note at 7.6(16.a) also needs a bit of repair.
+
+There is a similar problem with 7.6(18). It has a parenthetical "for nonlimited
+controlled types", but 7.6(21/2) is the rule that 7.6(17.1/2) is requiring to be
+implemented -- for both limited and nonlimited aggregates (and functions for that
+matter). It's quite clear that 7.6(21/2) *can* happen for limited types, the
+so-called proof of 7.6(18.a) notwithstanding.
+
+So I propose dropping "nonlimited" from 7.6(18) and fixing 7.6(18.a) to read
+something like:
+    Ramification: The rules below about assignment_statements apply only to
+    nonlimited controlled types, as assignment_statements are not allowed for
+    limited types. The other rule applies to both limited and nonlimited types,
+    and in fact is required for all assignment operations involving aggregates
+    and function calls. This is important because the programmer can count on
+    a stricter semantics for limited controlled types. 
+
+As both of these are parenthetical remarks, they don't affect the correctness of
+the language. As such, I propose to add these changes to the presentation AI.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent