tc39/proposal-iterator-helpers

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

zloirock opened this issue · 8 comments

zloirock commented

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 commented

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

benjamingr commented

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).

  • 👍1
bakkot commented

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.

  • 👍3
michaelficarra commented

Closing as nothing to do here.

zloirock commented

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

michaelficarra commented

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

zloirock commented

@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 commented

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).

  • 👍3