Normative: make async iterators next/return/throw not pass undefined when value is absent

[ljharb]

This is admittedly a very minor change.

const o = {
  next(...args) { console.log('args', args); return { done: true }; },
  [Symbol.iterator]() { return this }
};
for (const item of o) {}

logs 'args', []

(async () => {
  const o = {
    next(...args) { console.log('args', args); return { done: true }; },
    [Symbol.iterator]() { return this }
  };
  for await (const item of o) {}
})();

logs 'args', [undefined]. The intention of this change is to make async iteration match sync iteration from the perspective of a userland iterator next method.

This was an intentional decision made by the feature champion in tc39/proposal-async-iteration#113, but I don't recall it being discussed in committee. I find this inconsistency mildly troubling, and would like to correct it.

It has relevance as well for the "iterator helpers" proposal.

[ljharb]

This PR achieved consensus at today's TC39. It will first require at least one browser implementation committing to implement it, and merged test262 tests, and it being web compatible before this PR can be merged.

[ljharb]

@codehag has confirmed that SpiderMonkey is OK making the change, although we'll still have to wait for at least one shipping implementation due to web compat concerns.

[ljharb]

Tests PR: tc39/test262#2551

[shvaikalesh]

I will submit a patch for JSC as soon as the tests are merged & synced.

EDIT Apr 30: r260915

[ljharb]

Given that Firefox ships this and the next version of Safari is likely to as well, this seems like sufficient web compat data to me.

I'm going to remove the "needs data" label and rebase it; does anyone think that we should wait longer before landing it (modulo approvals)?

[bakkot]

Can we add a NOTE explaining that this optional argument is, in fact, always passed? (Since AsyncFromSyncIteratorPrototype objects are not user-observable and the only in-spec callsite, in yield *, always passes an argument.)

[ljharb]

Sure, but can you help me understand the value of noting that when the entire % AsyncFromSyncIteratorPrototype% object is already unobservable?

[bakkot]

Because it is unobservable, it's basically an abstract operation. By comparison, all abstract operations are unobservable, but it would still be surprising to define an abstract operation which took an optional parameter which was, in fact, always passed.

Here I don't really mind marking the parameter as optional and having logic for what to do if the argument is not passed (though now that I write this I guess I'd be happier still if we just asserted it were, but whatever), but since it's surprising, I think it would benefit from a NOTE.

[ljharb]

Note added.