es6now icon indicating copy to clipboard operation
es6now copied to clipboard

Translate "yield *" in Async Generator Functions

Open zenparsing opened this issue 10 years ago • 3 comments

What are the desired semantics? Clearly we should be able to delegate to other async iterators. What about synchronous iterators?

zenparsing avatar Aug 22 '14 02:08 zenparsing

There's a big issue with using yield * within async generators.

For sync generators, when the inner iterator is exhausted it won't return that iterator result to the client. Instead, it will take the value of that result and assign that value to the expression so that it can be captured in the generator.

With nested async iterators, we don't know whether we've exhausted the iterator until we've awaited the iterator result. That implies that we can't return anything to the client without awaiting each iteration. This is clearly not what we want from delegation.

There are two ways of looking at this result.

  1. Delegation doesn't make sense within async generators. Grammatically disallow yield * within async generator functions.
  2. This represents a deeper problem with the async iterator design.

For now, we'll go with viewpoint 1.

zenparsing avatar Aug 22 '14 18:08 zenparsing

Another option would be to allow yield * in async generators, but throw an error if the expression is an async iterator.

This would allow symmetry between async generators without await and regular generators, but seems confusing.

zenparsing avatar Aug 22 '14 19:08 zenparsing

After further thought, I think that intercepting and awaiting the result of the inner iterator makes sense.

This will take some translation to support, however.

More generally, it seems like we are moving to a design where all occurrences syntax-supported iteration are made async-aware, in the same manner that we currently have for for-of.

zenparsing avatar Aug 23 '14 15:08 zenparsing