CVS difference for ai12s/ai12-0047-1.txt

--- ai12s/ai12-0047-1.txt	2013/01/29 06:12:45	1.4
+++ ai12s/ai12-0047-1.txt	2013/02/01 01:30:59	1.5
@@ -1,4 +1,4 @@
-!standard 5.5.2(6/3)                                13-01-28    AI12-0047-1/04
+!standard 5.5.2(6/3)                                13-01-31    AI12-0047-1/05
 !class binding interpretation 12-12-01
 !status Amendment 202x 12-12-31
 !status work item 13-01-07
@@ -90,7 +90,7 @@
 the lifetime of the actual parameters to be short, as in the following
 example:
 
-   for I of Func_Returning_Array (Func_Returning_Record_With_Controlled_Components) loop
+   for E of Func_Returning_Array (Func_Returning_Record_With_Controlled_Components) loop
 
 In this case, the result of Func_Returning_Record_With_Controlled_Components is
 finalized before the loop begins to execute (assuming the parameter to
@@ -99,6 +99,23 @@
 is complete (as the loop statement is the master). This is what we want for
 generalized iterators, so no change is needed.
 
+There is no problem with more complex names, either. Consider:
+   for E of Func.Some_Array_with_Controlled_Components loop
+An iterator_specification contains an iterator_name or iterable_name; these are not
+expressions. As such, the entire name is not a master, either (a name is not in the
+list of the things that can be masters in 7.6.1(3/2)). Thus, in this case,
+Func.Some_Array_with_Controlled_Components is not a master, so its master is the
+entire loop statement; thus the master of the result of Func is also the entire
+loop statement, and the result of Func is not finalized until the iteration
+completes. This is what we want.
+
+Contrast this with the following:
+   for I in 1 .. Func.Some_Integer loop
+Here, Func.Some_Integer is an expression, this is a master by 7.6.1(3/2) as it is not
+enclosed by one of the things in the list in that rule. Thus the master of the result
+of Func is the master that is the Func.Some_Integer, and thus that result is finalized
+before the loop iterates. Again, this is what we want.
+
 !corrigendum 5.5.2(6/3)
 
 @dinsa
@@ -294,8 +311,9 @@
 > The other solution would be to treat these generalized iterators as
 > implicit renames, since you have already suggested that in part (1).
 
-Just fleshing out your suggestion, this approach would also include implicitly defining an enclosing block statement, right?
-The implicit rename declaration has to live somewhere.
+Just fleshing out your suggestion, this approach would also include implicitly
+defining an enclosing block statement, right? The implicit rename declaration
+has to live somewhere.
 
 ...
 > I haven't thought about whether analogous problems exist for the other