Automatic iterator.return() in contexts other than for and yield*

Jason Orendorff jason.orendorff at gmail.com
Wed Jan 14 11:36:58 PST 2015


In some cases a `for` loop will implicitly call `iterator.return()`:

    function gen() {
        try { yield 0; }
        finally { console.log("return was called"); }
    }

    for (let x of gen())
        throw "fail";  // logs "return was called"

This is to support iterators that want to clean up after themselves.

Destructuring assignment doesn't call `.return()`:

    let obj = {set x(v) { throw "fail"; }}
    [obj.x] = gen();  // return() is not called

Neither do the Map/Set/WeakMap/WeakSet constructors:

    class MySet extends Set {
        add(v) { throw "fail"; }
    }

    let m = new MySet(gen());  // return() is not called

Anyone remember the rationale for this? It seems like we should have
just one iteration protocol, and it should be "what `for` loops do",
including `iterator.finish()`. The collection constructors should be
as mannerly as `for`, right?

Anyone remember the reasoning? Is it something to consider changing in ES7?

-j


More information about the es-discuss mailing list