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
- 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.
@@ -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
Questions? Ask the ACAA Technical Agent