More tweaks for the iterator handling AOs #3311
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The iterator protocol has a bunch of helper AOs. But almost everything just uses
IteratorStepValue
(introduced in #3268) andIteratorClose
; the exceptions areIteratorStep
still gets used when you need to iterate but don't care about the value - specifically, it gets used for[foo, , bar] = baz
destructurings with elisions, and in some of the iterator helper proposals (e.g..drop
), which will need updating.IteratorNext
gets used in%AsyncFromSyncIteratorPrototype%.next
(the thing which handlesfor await
over a sync iterator)IteratorComplete
andIteratorValue
get used infor of
andyield *
so that they can share logic between sync vs async iteration, plus in%AsyncFromSyncIteratorPrototype
.This PR changes
IteratorStep
andIteratorNext
so that they set the[[Done]]
slot on the Iterator Record totrue
when some part of the protocol throws or the iterator result object's.done
is found to betrue
, consistent with howIteratorStepValue
behaves. (I'd previously considered eliminatingIteratorStep
entirely, but "I need to advance this iterator but I don't care about the value" is a coherent thing and does come up sometimes.)Of the above uses, only the "destructurings with elisions" case actually care whether the
[[Done]]
slot gets set totrue
, which it was previously doing explicitly. Still, it seems nicer to handle these uniformly, such that manipulation of that slot is done only in the iterator AOs themselves.This also incidentally eliminates 2 of the remaining 4 explicit uses of the ReturnIfAbrupt macro (cf #1573 (comment)), the last two being in
[[Call]]
and[[Construct]]
for ECMAScript function objects.