| 01:02 | <Justin Ridgewell> | Having yield that gave the promise. It should be the same if you're waiting on the next()'s return promise to settle |
| 01:03 | <Justin Ridgewell> | You could advance the generator body by manually calling next() again before the settlement, but that's the exact use case I'm trying to enable |
| 01:04 | <bakkot> | Justin Ridgewell: right, but that's kind of the point - if you've manually advanced the generator before settlement, then the throw completion will be injected at the wrong point |
| 01:07 | <Justin Ridgewell> | We could make it so that next(), throw(), and return() (the normal high-level APIs) all queue with backpressure to prevent that, and nextRaw() and the other raw low-level API allow you to manually advance |
| 01:22 | <Mathieu Hofman> | I'd be against adding yet another method to iterators, especially when next() can already have those semantics for iterators that support it. It just happens that an async generator creates and iterator that implicitly awaits the yielded values. Other kind of iterators may not |
| 03:30 | <Kris Kowal> | Notably, async iterators backed by promise lists do carry promise values and do not synchronize their resolution with transportation. |