zenparsing / es6now

ECMAScript 6 to 5 Compiler and Runtime Environment
MIT License
29 stars 2 forks source link

Translate "yield *" in Async Generator Functions #28

Open zenparsing opened 10 years ago

zenparsing commented 10 years ago

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

zenparsing commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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.