Normative: Add Array.fromAsync

[js-choi]

From proposal-array-from-async. Based on #2942 and tc39/proposal-array-from-async#50.

This is a draft for formal Stage 3 / 4 sign-offs (tc39/proposal-array-from-async#14) by the Editors, as per tc39/proposal-array-from-async#14 (comment).

There are currently several errors when building with ecmarkup 21.2.0. There are no more build errors except for a minor esmeta error, which is addressed by #3614.

CC: @syg, @bakkot, @michaelficarra

[bakkot]

The error for IfAbruptCloseAsyncIterator is because you are already introducing it as an AO, which automatically defines the term, but you are also putting a <dfn> around the term. The second is unnecessary.

The errors like "Call returns a Completion Record, but is not consumed as if it does" refer to the convention that every completion-returning AO should be invoked as ? Foo(), ! Foo(), or Completion(Foo()) to make it clear to the reader that this AO returns a completion record. In these cases I think the intention is to treat the value as a completion record and not immediately unwrap, so the solution is to wrap the call in Completion() as in Let _mappedValue_ be Completion(Call(...)).

The failure of the "enforce format" job can be fixed by running "npm run format", as it says.

Most of the other errors are pretty clear, I think, but let me know if there's any that are not. We can address them ourselves if you don't get to them first.

[js-choi]

ecmarkup / format errors have been fixed. This pull request is finally ready for Stage 3/4 sign-off from the Editors.

@nicolo-ribaudo, you might find this pull request more convenient to re-review than tc39/proposal-array-from-async#50 too.

There are minor build errors from esmeta that seem to be due to the algorithm’s use of the new IfAbruptCloseAsyncIterator operation.

We can do editorial refactoring later to make the algorithm use IteratorNext, IteratorComplete, and IteratorValue, like how Array.from now does.

Thanks to @bakkot for help, here and on Matrix.

[stonechoe]

If ESMeta doesn’t yet recognize the new operation, please feel free to ask us to add support rather than refactoring just to avoid build errors. If keeping IfAbruptCloseAsyncIterator makes the spec more readable than rewriting everything around IteratorNext, IteratorComplete, and IteratorValue, we’d prefer to leave it as-is. Let us know by opening an issue at ESMeta or dropping a comment, and we’ll get the new syntax supported.

There are minor build errors from esmeta that seem to be due to the algorithm’s use of the new IfAbruptCloseAsyncIterator operation.

We can do editorial refactoring later to make the algorithm use IteratorNext, IteratorComplete, and IteratorValue, like how Array.from now does.

[js-choi]

As a courtesy to the editors reviewing this pull request, I would like to explicitly propose making the following editorial changes:

• Change the “asyncItems” argument to “items”, since the items don’t have to be async.
• Change “This function” to “This async function” as per Normative: Add Array.fromAsync #3581 (comment).

[michaelficarra]

LGTM otherwise.

[michaelficarra]

I would like to explicitly propose making the following editorial changes:

WFM