Array.from accepts non-iterable array-like inputs (objects with a length property and indexed elements).

Should the inputs of Array.fromAsync be a superset of Array.from?

Are synchronous iterables/array-likes being iterated synchronously or asynchronously as they would in a for await? What is the expectation for a rejection within a sync collection that settles before to other promises prior? In a for await it goes unhandled. Would Array.fromAsync() be able to account for that and reject its returned promise or would it to allow for the unhandled rejection to slip through?

const delay = (ms, reject = false) => new Promise((r, j) => setTimeout(reject ? j : r, ms, ms));

for await (let ms of [delay(1000), delay(3000), delay(2000, true)]) {
  console.log(ms) // 1000, (unhandled error 2000), 3000
}

Consider this async iterable:

const it = {
  [Symbol.asyncIterator]() {
    return {
      async next() {
        if (i > 2) return { done: true };
        i++;
        return { value: Promise.resolve(i), done: false }
      }
    }
  }
}

Unless I'm reading the spec wrong, await Array.fromAsync(it) returns [Promise.resolve(1), Promise.resolve(2), Promise.resolve(3)] while await Array.fromAsync(it, x => x) returns [1, 2, 3].

Currently, when using Array.from, x => x is the "default mapper function" (even if it's not specified as such): Array.from(something) is always equivalent to Array.from(something, x => x). However, there is no "default function" that can be passed to Array.fromAsync.

If we changed Array.fromAsync(something) to await the next.value values, await Array.fromAsync(it) would always return the same result as await Array.fromAsync(it, x => x). In practice, it means making it behave like

const arr = [];
for await (const nextValue of it) arr.push(await nextValue);

I was working on test262 for this proposal, and I figured it'll be convenient if we had links to references of abstract operations that are defined in ecma262 spec (Eg: CreateAsyncFromSyncIterator).

This PR makes a small change to add those references.

Stage 2 iterator helpers proposal already contains %AsyncIteratorPrototype%.toArray method that does absolutely the same. What are the advantages has Array.asyncFrom?

On 64a49214f6a7036e7622ff4b4b9f938e277ae7ae, @zloirock left this comment:

this fallback will not properly work with sync iterators.

await Array.fromAsync([Promise.resolve(1), 2, Promise.resolve(3)]); // => [Promise.resolve(1), 2, Promise.resolve(3)]

Something like that could be simpler.

Let usingAsyncIterator be ? GetMethod(asyncItems, @@asyncIterator).
Let usingIterator be undefined.
If usingAsyncIterator is undefined,
  Let usingIterator be ? GetMethod(asyncItems, @@Iterator).
  If usingIterator is undefined,
    Let usingIterator be ? %Array.prototype.values%.
...
If usingAsyncIterator is not undefined,
  Let iteratorRecord be ? GetIterator(asyncItems, async, usingAsyncIterator).
Else,
  Let syncIteratorRecord be ? GetIterator(asyncItems, sync, usingIterator).
  Let iteratorRecord be ? CreateAsyncFromSyncIterator(syncIteratorRecord).

The problem is that the current specification will not properly await each value yielded from a synchronous iterator. (We do want await to be called on each value from a synchronous iterator—this is what for await does.)

This problem is due to how the spec currently incorrectly creates an synchronous iterator. Step 3.e.iii assigns iteratorRecord to GetIterator(asyncItems, async, usingAsyncOrSyncIterator), which results in a synchronous iterator that does not call await on each of its yielded values. What we need to do is copy GetIterator when it is called with an async hint. We need to call CreateAsyncFromSyncIterator on the created sync iterator, which in turn will create an Async-from-Sync Iterator object, whose next method will call await on each of its values. (Thanks @bakkot for the help).

I will fix this later.

Other recent proposals adding methods to Array.prototype have added the name to Array.prototype[@@unscopables] -- I sort of imagine fromAsync should get added too.

Resolves #31, at least temporarily. (Also affects #14.)

Eventually we might want to make a change to match whatever approach proposal-iterator-helpers does; see tc39/proposal-iterator-helpers#218. But that should be able to be a mere editorial change.

fromAsync makes use of an Abstract Closure passed to AsyncFunctionStart. What is the return type of this closure? The use of ? implies it must be a Completion Record, but there's also a bare Return A. which returns a value not wrapped in a completion record. In normal built-in functions this would be implicitly wrapped in NormalCompletion by the rules in this clause, but a.) that doesn't apply within the Abstract Closure (rather, it's the thing which allows the final Return promiseCapability.[[Promise]] line to work and b.) that wouldn't do the right thing anyway, because the logic in AsyncBlockStart treats an invocation returning a normal completion as if it had explicitly returned undefined (which is how normal functions work) - an actual return would be a return completion.

I see three possible ways forward:

1. in the closure within fromAsync, explicitly wrap each Return _value_. as Return Completion Record { [[Type]]: ~return~, [[Value]]: _value_, [[Target]]: empty }
2. in AsyncFunctionStart, have a different path for Abstract Closures vs built-in functions
3. define "built-in async function" rigorously in a way which would allow you to write the steps of a built-in function, but using Await

Of these I think the third option is cleanest, especially if we add more built-in async stuff (as the iterator helpers proposal will do).

Now, in the spec draft we have:

However, in related methods of iterator helpers proposal, we await the result of the mapper:

It should be consistent.

The exciting iterator-helpers proposal has a similar toArray method that overlaps with this. (toArray already overlaps with Array.from too.) See #1.

My preference is to keep both toArray and Array.fromAsync (Array.from being a fait accompli). But we can explore this more before both proposals advance further. CC: @codehag

As of the September meeting, this proposal is now at stage 3. See https://github.com/tc39/notes/blob/HEAD/meetings/2022-09/sep-14.md#arrayfromasync-for-stage-3.

See https://github.com/tc39/proposal-iterator-helpers/pull/245 and https://github.com/tc39/ecma262/pull/2942. This will align our efforts and allow reviewers to focus on the actual content of this proposal.

As written, the spec -may- double counstruct A:

It will be constructed first as part of Step 3.{e,f}; then if iteratorRecord is undefined, it's constructed again in Step 3.k.{iv,v}.

Probably that first construction could be sunk into 3.j.

In the published spec, Step 3.j.ii.3 and 4 are the termination condition of the iteration:

• Step 3.j.ii.3 "Let next be ? Await(IteratorStep(iteratorRecord))."
• Step 3.j.ii.4 "If next is false, then..."

The problem is that IteratorStep doesn't properly flag termination on an async iterator; the return value of the IteratorNext in async iteration is a Promise, which doesn't have a "done" property, and so we always get the promise object from IteratorStep.

I think the patch is actually relatively simple; Step 3.j.ii.4 should be expanded into the steps which have the effect of "if next.done is false:"

Hey, I was wondering, since Array.fromAsync(iter) is similar to AsyncIterator.from(iter).toArray() wouldn't it make sense if they shared the same spec text? That is one (for example fromAsync) is defined and the other is defined in terms of it?

(I agree that it makes sense to have both as it's more ergonomic and people will likely reach out to both - though that's not the discussion here)