CVS difference for ai05s/ai05-0067-1.txt
--- ai05s/ai05-0067-1.txt 2008/11/18 05:45:26 1.10
+++ ai05s/ai05-0067-1.txt 2008/11/18 20:57:17 1.11
@@ -1,4 +1,4 @@
-!standard 4.3.2(5/2) 08-11-17 AI05-0067-1/07
+!standard 4.3.2(5/2) 08-11-18 AI05-0067-1/08
!standard 7.5(8.1/2)
!standard 7.5(9/2)
!standard 7.6(0)
@@ -6,6 +6,8 @@
!standard 7.6(17/2)
!standard 7.6(17.1/2)
!standard 7.6(18)
+!standard 7.6(19)
+!standard 7.6(20)
!standard 7.6(21/2)
!class binding interpretation 07-10-22
!status ARG Approved 6-0-1 08-11-02
@@ -133,7 +135,7 @@
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
-implementations and users. [This note was 7.5(8.e/2) - ED]
+implementations and users. [This note was 7.5(8.a/2) - ED]
Notwithstanding what this International Standard says elsewhere, if an object
is built in place:
@@ -200,15 +202,31 @@
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).
+Modify 7.6(18) as follows:
+An implementation is allowed to relax the above rules [(for nonlimited controlled types)]
+{for assignment_statements} in the following ways:
+
+Modify 7.6(19) as follows:
+
+ [For an assignment_statement that assigns to]{If} an object {is assigned }the value
+ of that same object, the implementation need not do anything.
+
+Modify 7.6(20) as follows:
+
+ For [an assignment_statement for]{assignment of} a noncontrolled type,
+ the implementation may finalize and assign each component of the variable
+ separately (rather than finalizing the entire variable and assigning the
+ entire new value) unless a discriminant of the variable is changed by the
+ assignment.
+
Modify 7.6(21/2) as follows:
- [For an aggregate or function call whose value is
- assigned into a target object, the implementation need not create a
- separate anonymous object if it can safely create the value of the
- aggregate or function call directly in the target object. Similarly,
- for]{For} an assignment_statement, ...
+ [For an aggregate or function call whose value is
+ assigned into a target object, the implementation need not create a
+ separate anonymous object if it can safely create the value of the
+ aggregate or function call directly in the target object. Similarly,
+ for an assignment_statement, the]{The} implementation need not...
!discussion
@@ -441,10 +459,33 @@
@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 @fa<assignment_statement>s
+in the following ways:
+
+!corrigendum 7.6(19)
+
+@drepl
+For an @fa<assignment_statement> that assigns to an object the value
+of that same object, the implementation need not do anything.
@dby
-An implementation is allowed to relax the above rules (for controlled types) in
-the following ways:
+If an object is assigned the value of that same object, the implementation need
+not do anything.
+!corrigendum 7.6(20)
+
+@drepl
+For an @fa<assignment_statement> for a noncontrolled type,
+the implementation may finalize and assign each
+component of the variable separately (rather than finalizing the entire
+variable and assigning the entire new value)
+unless a discriminant of the variable is changed by the assignment.
+@dby
+For assignment of a noncontrolled type, the implementation may finalize and assign
+each component of the variable separately (rather than finalizing the entire variable
+and assigning the entire new value) unless a discriminant of the variable is changed
+by the assignment.
+
!corrigendum 7.6(21/2)
@drepl
@@ -461,7 +502,7 @@
not at all (for an assignment where the target and the source of the assignment
are the same object).>
@dby
-@xbullet<For an @fa<assignment_statement>, the implementation need not
+@xbullet<The implementation need not
create an anonymous object if the value being assigned is the result of
evaluating a @fa<name> denoting an object (the source object) whose storage cannot
overlap with the target. If the source object might overlap with the target
@@ -1788,6 +1829,92 @@
is exactly the case that convinced me you were right and I was off base. Clearly
when you return one of these beasts and it is not built in place, the controlled
components need to be adjusted.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 17, 2008 10:51 PM
+
+I noticed that after applying the changes of AI05-0067-1, we have the three
+bullets here that all start with "For an assignment_statement...". That looks
+silly.
+
+Moreover, the lead-in starts "An implementation is allowed to relax the above
+rules (for controlled types)...", but the second bullet applies only to
+non-controlled types, so it surely isn't relaxing any controlled type rules!
+This is confusing (at least to me). I think it would be better to talk about
+relaxing rules for assignment, since we're really talking about relaxing 7.6(13-17)
+in a number of special cases. (Those rules are mainly visible in the case of
+controlled types, but that seems like unnecessary information when defining the rules.)
+
+So I think these paragraphs should be changed to something like:
+
+
+An implementation is allowed to relax the above rules for assignment_statements
+in the following ways:
+
+* If an object is assigned the value of that same object, the implementation need
+not do anything.
+
+* For assignment of a noncontrolled type, the implementation may finalize and assign
+each component of the variable separately (rather than finalizing the entire variable
+and assigning the entire new value) unless a discriminant of the variable is changed
+by the assignment.
+
+* The implementation need not create an anonymous object if the value being assigned
+is the result of evaluating a name denoting an object (the source object) whose
+storage cannot overlap with the target. If the source object might overlap with
+the target object, then the implementation can avoid the need for an intermediary
+anonymous object by exercising one of the above permissions and perform the assignment
+one component at a time (for an overlapping array assignment), or not at all (for
+an assignment where the target and the source of the assignment are the same object).
+
+
+Should this be done? (Or something like it?) If so, should this be done as part of
+the editorial review of AI05-0067-1, or do we have to create a separate AI for it?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, November 17, 2008 10:58 PM
+
+Feels like an editorial review kind of thing to me.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, November 17, 2008 11:11 PM
+
+You didn't say whether you thought the change *ought* to be done. That's slightly
+more important than *how* it is done. :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, November 17, 2008 11:20 PM
+
+Sorry, I thought that was implicit. Yes, I like your rewording.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 18, 2008 7:57 AM
+
+>> Feels like an editorial review kind of thing to me.
+
+Ditto, and it is an (explicitly!) an improvement.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, November 18, 2008 8:21 AM
+
+> Sorry, I thought that was implicit. Yes, I like your rewording.
+
+Same here. FWIW, I like this AI. Much better than the original Amendment.
+
+Two typos in the AI in the AARM Discussion after 7.6(17): "Ada 95.We"
+should be "Ada 95. We" and 7.5(8.e/2) should be 7.5(8.a/2).
****************************************************************
Questions? Ask the ACAA Technical Agent