Proposal to reconsider avoiding exposing of %AsyncFromSyncIteratorPrototype%

[zloirock]

Related to #182 (an extra wrapper for %AsyncFromSyncIteratorPrototype%)

The previous discussion in #172

I agree that the previous approach is observable and will cause a problem for optimization. However, the new approach also will cause a problem with optimization.

I don't wanna analyze the spec completely, but

await AsyncIterator.from([1]).toArray();

in my testing environment, before #182 runs microtasks 16 times, after - 24, I'm not sure about the correct number of ticks since some of them can be used for some other internal needs. However, this number makes me think about the need for such a change.

Removing extra ticks is a problem that now TC39 tries to solve - tc39/ecma262#2772 - and here we have such increasing.

Maybe makes sense to use another approach? For example, to make %AsyncFromSyncIteratorPrototype% exposing, but operations on it unobservable. How? For example, make .next, .return and .throw on this object non-writable / non-configurable.

[bakkot]

I think this is more of a problem with WrapForValidAsyncIteratorPrototype, actually - it can directly return the value from the underlying iterator, like WrapForValidIteratorPrototype does, instead of creating and resolving a Promise.