Currently the Set and Map iterator next methods are specified using "loop" language, but they are not generators: they are prototype methods. It would be much more clear if they were written as the ArrayIterator specification is.
Currently they are missing a bit that when they are finished, to set the nextIndex to +Infinity in order to prevent the iterators from coming back to life.
So there are two issues here. Regarding the loop, I misinterpreted the language to imply that the loop was a generator loop and not just a normal part of a method specification. The spec is not ambiguous there, though it could be clearer.
For the second, that iterators can come back to life -- I thought the spec was an unintentional thing. If that is not the case, two points:
* Calling next on an iterator that is already at the last insertion position should not advance the insertion position. This way you can:
var o = Map();
var i = o[@@iterator]();
i.next() // { value: undefined, done: true }
o.put('foo', 'bar');
i.next() // { value: 'foo', done: false }
i.next() // { value: undefined, done: true }
* The behavior of the map iterator should be consistent with the array iterator. If the map iterator can come back to life, then the same with the array iterator.
I tend to think that iterators should stay done once they are done for the first time, but YMMV.
(In reply to comment #1)
> * The behavior of the map iterator should be consistent with the array
> iterator. If the map iterator can come back to life, then the same with the
> array iterator.
This point is very compelling. They should be consistent.
Permanently closing the iterator seems best.
It's unintentional that they can come back to life. I'll change that.
The loop is simply an incidental artifact of the specification's linear data structure and is needed to skip over deleted elements. Most of the Map/set algorithms have some sort of loop, like this.
fixed in rev20 editor's draft
fixed in rev20 draft, Oct. 28, 2013