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