On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:

> On 9/10/14, 1:47 PM, Allen Wirfs-Brock wrote:
>>> 1. Let method be the result of CheckIterable(V).
>>> 2. ReturnIfAbrupt(method).
>>> 3. If IsCallable(method) is false, go off and do something else,
>>>   since V is not iterable.
>>> 4. Let iter be GetIterator(V, method).
>>> 5. ReturnIfAbrupt(iter).
>>> 
>>> and then IteratorStep my way through "iter".
>> 
>> So, try expressing this in JS. That's what a JS help-hosting compliant implementation is going to have to do.
> 
> Sure.
> 

> var method = V[Symbol.iterator];
>  var method = V[Symbol.iterator];
>  if (typeof method != "function") {
>    // Not iterable; do something else
>  }
>  var iter = method.call(iter);
> 
> and then go through calling .next() and so on.
> 
> Now in this self-hosted case, how do I express IteratorClose?  

why wouldn't a self-hoster just continue with:
  for (let next of iter} {
   /* body */
  }
which will do all the IteratorClose work for them. In fact, isn't that how we want a self-hoster to code it. 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. 

> Seems to me like it's just a matter of wrapping the relevant bits (which ones, though?
whatever constitutes the loop "body"
> ) in a try/catch and doing this in the catch clause:
> 
>  catch (e) {
>    if ("return" in iter) {
>      iter.return();
>    }
>    throw e;
>  }
> 
> That ought to match the semantics of IteratorClose, yes?

You also will need a finally clause, if the loop body contains any explicit returns.

Allen

On Sep 10, 2014, at 10:58 AM, Boris Zbarsky wrote:

> Now in this self-hosted case, how do I express IteratorClose?  

why wouldn't a self-hoster just continue with:

```js
for (let next of iter} {
 /* body */
}
```

which will do all the IteratorClose work for them. In fact, isn't that how we want a self-hoster to code it. 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. 

> Seems to me like it's just a matter of wrapping the relevant bits (which ones, though?

whatever constitutes the loop "body"

> ) in a try/catch and doing this in the catch clause:
> 
> ```js
>  catch (e) {
>    if ("return" in iter) {
>      iter.return();
>    }
>    throw e;
>  }
> ```
>
> That ought to match the semantics of IteratorClose, yes?

You also will need a finally clause, if the loop body contains any explicit returns.