Don't fallback to Symbol.iterator in async iteration statement

[zenparsing]

Looking over this again, the behavior where we fallback to using Symbol.iterator if the iteration subject does not have Symbol.asyncIterator feels hacky.

I think it should only look for Symbol.asyncIterator. If we want to, we can add async iteration support to regular iterators by adding a method to `%IteratorPrototype%.

[RangerMauve]

I think adding Symbol.asyncIterator to the IteratorPrototype would be absolutely necessary if regular iteraters won't work. Also, what if it's a regular iterator that yields promises?

[zenparsing]

Also, what if it's a regular iterator that yields promises?

Then it's not a regular iterator ; )

A regular (synchronous) iterator must return IterationResult objects. An async iterator must return Promise<IterationResult> objects.

[RangerMauve]

Ah! That makes sense.

[RangerMauve]

What does the async function spec say about using await on non-promises? If it errors out then I think that it would make sense for for async to error out if one tries to iterate over something that isn't an async iterator

[zenparsing]

@RangerMauve awaiting a non-promise is equivalent to awaiting a promise which is immediately fulfilled with that value.

[RangerMauve]

I would argue, then, that if something other than an asyc iterator gets passed in, it should be treated as a regular iterator, but maybe the actual iteration should use microtasks so that it isn't sync.

[zenparsing]

Wow, it's been a while since that last comment, but @RangerMauve I think you're right.

[RangerMauve]

:D Woot!

[groundwater]

I have been working with async iterators in my last project, so I thought I'd add my thoughts.

I believe the power of async iterators comes from composing them into larger computations. Each step may do some I/O, for example the first iterator may yield account ids which the second iterator then takes and returns the corresponding row form a database.

I have run into cases where a step of the computation can be 100% synchronous, e.g. performing some mathematical transform on values. I'd rather write the synchronous code within the iterator, but from the outside I don't want to give it special treatment.

Thus I'd agree with the above. It should be fine to pass in synchronous iterator, but they should behave like the asynchronous ones from the consumer perspective.

[zenparsing]

All agreed, so closing : )

[zenparsing]

Reopening due to some concern raised at TC39 about falling back to Symbol.iterator.

[RangerMauve]

What was the concern specifically?

[zenparsing]

About fallback in general, where adding a method to an existing type would change behavior in for-await statements. I just wanted to re-open so that I didn't forget to come back to this later.