Disallow primitives in GetIterator() for async iterables

[petamoriken]

Normative conversion have been approved for iterables that will no longer be converted from primitives (tc39/how-we-work#152). There is currently no specification for async iterable to be converted from primitives, and the Web IDL converter is currently working on allowing only objects (whatwg/webidl#1397).

I think it would be better to disallow primitives in GetIterator() for async iterables, since it will probably not cause break the web.

[michaelficarra]

From what I can tell, GetIterator is used to get async iterators for for-await-of loops and yield* inside async generators. I'd be surprised if nobody was using either of those with strings. Is there a good reason to try to do this?

The normative conventions are meant to apply as guiding principles for new features going forward. We did not expect them to be able to be applied retroactively to existing features like this.

[ljharb]

indeed, (async () => { for await (const x of 'abc') { console.log(x); } })() already works, so i'm not sure how it would be web compatible to change it.

[petamoriken]

If only 1.a. of GetIterator is changed, it seems to be possible to change it without any problem for strings. However, I am not sure if that change is effective.

1. If kind is async, then
   a. Let method be ? GetMethod(obj, %Symbol.asyncIterator%).
   b. If method is undefined, then ...

On the topic of the normative conventions, it might be better to reject primitives in Stage 3 Array.fromAsync. cc: @js-choi

[michaelficarra]

However, I am not sure if that change is effective.

Effective at what? What are you trying to achieve? Consistency for how primitives are handled in async iterator taking positions?

[petamoriken]

Main motivation is that we can prohibit prototype pollution for primitives such as Number.prototype[Symbol.asyncIterator]. It is nonsense to make primitives async iterable.