Awaiting of `IteratorValue` in `%AsyncIteratorPrototype%` methods

[zloirock]

See the original issue in the Array.fromAsync proposal. The same is applicable to %AsyncIteratorPrototype% methods.

const i = 0;

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

I think that it should be agreed upon between both proposals.

[ljharb]

Async iterator helpers should be awaiting the value too, I’d expect.

[benjamingr]

I would expect the behavior to be the same as async iterators in `for await. That is, tc39/proposal-async-iteration#15 (unfortunately, I don't particularly like this behaviour).

[bakkot]

I agree with the OP that they should match. I like the behavior currently in this proposal, which is what you'd get with for await, which would result in the code in the OP resulting in an array containing three promises.

[michaelficarra]

Closing as nothing to do here.

[zloirock]

@michaelficarra why? It's still not aligned between both proposals and the inconsistency should be resolved.

[michaelficarra]

@zloirock The inconsistency can be resolved by this proposal remaining unchanged and the Array.fromAsync proposal changing. So nothing to do here.

[zloirock]

@michaelficarra as you can see, they (at least @ljharb and @js-choi) decided to change the behavior that's used here. So, please, instead of ignoring this issue, align it - I don't care on what side. I'm (and it seems all the rest) pretty sure that those methods should use one approach.

[js-choi]

For what it’s worth, I’ve come around to the old behavior of Array.fromAsync, which matches the iterator-helpers spec. See tc39/proposal-array-from-async#19 (comment).