for-of loops, IteratorClose and the rest of the iterations in the spec

Allen Wirfs-Brock allen at
Wed Sep 10 13:11:51 PDT 2014

On Sep 10, 2014, at 12:41 PM, Boris Zbarsky wrote:

> On 9/10/14, 3:20 PM, Allen Wirfs-Brock wrote:
>> why wouldn't a self-hoster just continue with:
>>   for (let next of iter} {
>>    /* body */
>>   }
> I feel like I'm missing something here.
> "iter" is an iterator, not an iterable.  So I don't think this will do the right thing, unless I'm seriously missing something.

In practice (because of for-of semantics) Iterators need to be Iterables that return themselves as the associated iterator.  All built-in iterators in ES have this characteristic

>> Anything either ES or WebIDL does that is hostile to that pattern is counter productive  as self-hosters are probably going to do that anyway, even if the semantics is a slight mismatch to the spec.
> What I am trying to define in Web IDL is the semantics of methods that take an argument which is either an iterable or something else.  That means they need to check whether the given thing is iterable, and if so iterate, otherwise do something else.  See the thread that ended up in and the algorithm in that mail; that's what I'm specifying.

For example, Array.from does that kind of argument discrimination: 
>>> Seems to me like it's just a matter of wrapping the relevant bits (which ones, though?
>> whatever constitutes the loop "body"
> OK.  That's fairly straightforward.
>> You also will need a finally clause, if the loop body contains any explicit returns.
> It only does when the iterator claims there are no more things to be had, in which case do I still want to be calling the return() thing?

No, you only call 'return' when exiting the loop before the iterator has indicated that it is 'done'..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list