http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-iteratordestructuringassignmentevaluation
Is this intentional? IteratorDestructuringAssignmentEvaluation of the production
> AssignmentElement : DestructuringAssignmentTarget Initializer_opt
calls IteratorStep unconditionally. This means that if an ArrayAssignmentPattern contains multiple such AssignmentElements, and iterator.next() returns {done:true} when called for the first element, it will be called again for the other elements anyway.
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-iterator-interface requires that a valid Iterator implementation must continue to return {done: true} on subsequent calls to next.
Of course there is not guarantee that an user provided supposed iterator will behave that way, but nothing else we assume is guaranteed either. There may not even be a next method or it might disappear after a few iterations. Regardless, the behavior of a destructuring assignment is fully specified (relative to the behavior of the iterator object), even for cases where the supposed iterator is poorly behaved.
(Also, note that iterator.next() is also called unconditionally at least once for an AssignmentRegElement.)
I could add extra logic to the spec. to keep track of whether the iterator that is being used has ready reported done: true and not make the iterator.next() calls in that case. But I'm not sure that it would be any better if we did that. It would add complexity to the spec. and probably to implementations but it still wouldn't guarantee that the iterator won't misbehave in other ways.
Given all the ways that destructing can fail to complete normally, trying to do something about this one form of failure doesn't seem necessary.
But, if you have a stronger argument for explicitly tracking done, I'd be happy to consider it.
[Changing this bug's 'Version' from rev23 to rev25, as it seems just as relevant to rev25, and there's not much point raising it against an old version.]
I looked at this again today and changing the spec. the destructuring spec. to stop calling spent iterators would still require significant spec. changes and I still don't seen any actual problems it creates.
I'm resolving it as won't fix.