-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: add Iterator Helpers #3395
Conversation
7879f32
to
0bf3656
Compare
@@ -6956,6 +6996,28 @@ <h1> | |||
</emu-alg> | |||
</emu-clause> | |||
|
|||
<emu-clause id="sec-getiteratorflattenable" type="abstract operation"> | |||
<h1> | |||
GetIteratorFlattenable ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love to come up with a better name for this AO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment was about GetIteratorFlattenable
(it's no longer displaying under the appropriate line in the diff view).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks right on the conversation view, at least
2db9b31
to
78c9237
Compare
This comment was marked as resolved.
This comment was marked as resolved.
b7e5f5f
to
189e3d6
Compare
2255ce1
to
0cb2376
Compare
FYI we're having a relevant editorial discussion here: tc39/proposal-joint-iteration#30 |
322876c
to
380047c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR seems to be missing changes to CreateIteratorFromClosure to add a 4th argument? (present in the proposal spec)
@tc39/ecma262-editors Do we want to make the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I no longer think we should rename [[UnderlyingIterators]]
now, since it would also involve changing its handling; we can do that in the followup.
1. If _O_.[[GeneratorState]] is ~suspended-start~, then | ||
1. Set _O_.[[GeneratorState]] to ~completed~. | ||
1. NOTE: Once a generator enters the completed state it never leaves it and its associated execution context is never resumed. Any execution state associated with _O_ can be discarded at this point. | ||
1. Perform ? IteratorClose(_O_.[[UnderlyingIterator]], ReturnCompletion(*undefined*)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this Return Completion could be returned by IteratorClose
, and thus by this algorithm, and thus by the [[Call]]
for this built-in. But the invariants for essential internal methods don't allow [[Call]]
to return a Return Completion.
Co-authored-by: Michael Ficarra <m.ficarra@f5.com> Co-authored-by: Michael Dyck <jmdyck@ibiblio.org>
60fcae2
to
961f269
Compare
Co-authored-by: Michael Ficarra <m.ficarra@f5.com> Co-authored-by: Michael Dyck <jmdyck@ibiblio.org>
https://github.com/tc39/proposal-iterator-helpers