ix behavior in relation to spec for Iterator Helpers

[michaelsbradleyjr]

Earlier this year I made a request for clarification to the core-js project re: the behavior of that project's implementation of AsyncIterator and the helper APIs.

What it boiled down to: ix and JS built-in for await...of did what I expect while core-js didn't. See the following:

const AsyncIterator = require('core-js-pure/features/async-iterator');

const ps = [Promise.resolve(1), 2, Promise.resolve(3)];

(async () => {
  const arr = [];
  await AsyncIterator.from(ps).forEach(v => arr.push(v));
  console.log(arr) // => [ Promise{ 1, ... }, 2, Promise{ 3, ... } ]
})();

const { from: ixFrom } = require('ix/asynciterable');

const ps = [Promise.resolve(1), 2, Promise.resolve(3)];

(async () => {
  const arr = [];
  await ixFrom(ps).forEach(v => arr.push(v));
  console.log(arr) // => [ 1, 2, 3 ]
})();

const ps = [Promise.resolve(1), 2, Promise.resolve(3)];

(async () => {
  const arr = [];
  for await (const v of ps) {
    arr.push(v)
  }
  console.log(arr) // => [ 1, 2, 3 ]
})();

Earlier today the maintainer weighed in and pointed out that core-js is following the spec.

If/when Iterator Helpers makes it into ES202X, this subtle difference seems like it could be a cause for confusion, but there may be an aspect that I'm not appreciating. Do the maintainers of this project think it's better to align with a conceptually related spec (albeit a draft) or for this project to go its own way? Or maybe this is a problematic area in the spec and an issue should be raised with its authors? Thoughts?

[trxcllnt]

Oh my

[conartist6]

Wow, that's interesting. I'm going to take a look at this in iter-tools as well.

[conartist6]

My initial reaction is that it should be raised with the spec authors. I'm biased as a library maintainer but I expect it to be possible to implement forEach using for..of. I think I'd also expect the mechanics to be equivalent as a user. It's a big deal for libraries too because this will affect many methods, not just forEach. If the spec says that none of them can be implemented safely with for..of loops, then that's a huge headache.

[zloirock]

It's fixed in current versions of core-js and proposal.