On Apr 24, 2014, at 1:29 PM, Brendan Eich wrote:

> Sorry for the confusion -- my "such a change" was about changing @@iterator 
> itself, e.g. not defining it on a generator, or trying somehow to guarantee 
> freshness.
> 
> I agree, return automation makes sense for any delimited form that implicitly 
> calls @@iterator.
> 
> There still may be an open issue, though: Python has ref-counting and 
> pre-mortem finalization via close, last I checked. JS won't have any such 
> thing. So are there ,in ES6, undelimited forms that implicitly call 
> @@iterator and that won't implicitly maybe-call return?
> 

I don't think so, although I need to do an inspection (which will be required 
anyway to actually update the spec.). As far as I can recall, all uses of 
@iterator in the spec. are in loop that intend to run to completion.  It is 
only  potential abnormal completion sites between 'next' calls (of which there 
can be plenty of as any MOP level operation can throw)  that need to be dealt 
with.  For example, here is the relevant loop from Array.from:


(the following is actually starts at step 6 in the spec.)
        • 1.    Let usingIterator be CheckIterable(items).
        • 2.    ReturnIfAbrupt(usingIterator).
        • 3.    If usingIterator is not undefined, then
                • a.    If IsConstructor(C) is true, then
                        • i.    Let A be the result of calling the 
[[Construct]] internal method of C with an empty argument list.
                • b.    Else,
                        • i.    Let A be ArrayCreate(0).
                • c.    ReturnIfAbrupt(A).
                • d.    Let iterator be GetIterator(items, usingIterator).
                • e.    ReturnIfAbrupt(iterator).
                • f.    Let k be 0.
                • g.    Repeat
                        • i.    Let Pk be ToString(k).
                        • ii.   Let next be IteratorStep(iterator).
                        • iii.  ReturnIfAbrupt(next).
                        • iv.   If next is false, then 
                                • 1.    Let putStatus be Put(A, "length", k, 
true).
                                • 2.    ReturnIfAbrupt(putStatus).
                                • 3.    Return A.
                        • v.    Let nextValue be IteratorValue(next).
                        • vi.   ReturnIfAbrupt(nextValue).
                        • vii.  If mapping is true, then
                                • 1.    Let mappedValue be the result of 
calling the [[Call]] internal method of mapfn with T as thisArgument and 
(nextValue, k) as argumentsList.
                                • 2.    ReturnIfAbrupt(mappedValue).
                        • viii. Else, let mappedValue be nextValue.
                        • ix.   Let defineStatus be 
CreateDataPropertyOrThrow(A, Pk, mappedValue).
                        • x.    ReturnIfAbrupt(defineStatus).
                        • xi.   Increase k by 1.

@@iterator isn't call until step 3d. Steps 3.g.iii, 3.g.vi, 3.g.vii.2, and 
3.g.x are all possible abnormal loop exit points that should call @@return if 
needed.

Allen

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to