-
Notifications
You must be signed in to change notification settings - Fork 16
Redefine fromAsync as “built-in async function” #50
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
base: main
Are you sure you want to change the base?
Conversation
The “Iterator Abstract Operations” subsection of “Iteration” from the old version of proposal-iterator-helpers and proposal-async-iterator-helpers is obsolete. This means that the new IfAbruptCloseAsyncIterator operation (shared with proposal-async-iterator-helpers) no longer has a place to live. The ecma262 spec placed proposal-iterator-helpers’ analogous IfAbruptCloseIterator operation into a “Operations on Iterator Objects” subsection of “Abstract Operations”. This commit places IfAbruptCloseAsyncIterator into an analogous “Operations on Async Iterator Objects” subsection…although Async Iterator Objects do not yet exist! The editors may choose to name this new subsection whatever they want. Or they might elect to not make a new subsection and foist IfAbruptCloseAsyncIterator on the existing “Operations on Iterator Objects” subsection instead, until proposal-async-iterator-helpers makes Stage 4. This is an editorial change.
FYI, I pushed an editorial change to the new IfAbruptCloseAsyncIterator operation’s location. The “Iterator Abstract Operations” subsection of “Iteration” from the old version of proposal-iterator-helpers and proposal-async-iterator-helpers is obsolete. This means that the new IfAbruptCloseAsyncIterator operation (from #25, shared with proposal-async-iterator-helpers) no longer has a place in the spec to live. The ecma262 spec placed proposal-iterator-helpers’ analogous IfAbruptCloseIterator operation into a “Operations on Iterator Objects” subsection of “Abstract Operations”. This commit places IfAbruptCloseAsyncIterator into
Since this is a merely editorial tweak to the pull request, I don’t think the tweak deserves scrutiny until I make a pull request on tc39/ecma262#2942. |
…ns on Iterator Objects” This matches the spec’s use of “Operations on Iterator Objects” to contain async iterable operations AsyncIteratorClose.
This matches ecma262’s IfAbruptCloseIterator.
* IfAbruptCloseAsyncIterator now directly uses the return value of AsyncIteratorClose. This is an editorial change. * Editorial formatting changes have been done, e.g., avoiding unnecessary HTML entities and making if/else subclauses use blocks if any alternative branch uses blocks.
Please note that the proposal-array-from-async proposal is out of date and still has a pending pull request (tc39/proposal-array-from-async#50). The most up-to-date version is the tc39/ecma262#3581 pull request linked in the table.
Please note that the proposal-array-from-async proposal is out of date and still has a pending pull request (tc39/proposal-array-from-async#50). The most up-to-date version is the tc39/ecma262#3581 pull request linked in the table.
This tweaks the spec to use the new “built-in async function” machinery in tc39/ecma262#2942. It resolves #43. See also #31, #36.
aoid
attribute for IfAbruptCloseAsyncIterator. This is an editorial change.This is the last step before creating a pull request to tc39/ecma262 (along with resolving the merge conflicts of tc39/ecma262#2942). We’re almost there.
@nicolo-ribaudo, @ljharb, since you reviewed it before for Stage 3 (#14), would you mind reviewing before we merge this?