Is the AsyncGeneratorQueue really necessary?

[rauschma]

After receiving a promise from next(), would it ever make sense to call next() again before that promise is settled? After all, done tells you whether you should continue iterating or not.

If not then one could simply throw an error if next() is called before the previously returned promise is settled and no queue would be needed.

[domenic]

Yes, there are many cases where you want to get promises for multiple values at once, e.g. to Promise.all them.

Going to close this since this kind of fundamental design change is not in the cards for stage 3, but happy to continue discussion in the closed issue.

[rauschma]

Being able to use Promise.all() would indeed be useful. But how does that work – given that queuing happens without looking at done?

[domenic]

As a simple example, let's say you know by contract that the API will always return at least two values or error along the way (i.e. it will never return 1 value then exit). Then:

const [{ value }, { value }] = await Promise.all([ag.next(), ag.next()]);

[zenparsing]

@rauschma Another practical example might be when you're using an async generator as a sink (e.g. when writing to a file). In that case, you might want to next(chuck) a bunch of chunks and the return() to close the file, without necessarily waiting for each next to complete:

A contrived example:

writer.next(bufferA);
writer.next(bufferB);
await writer.return(); // Only wait for the file to close

More abstractly, if we made the generator reject when a next operation was in-flight, we'd be injecting a kind of statefull-ness that we probably don't want, in which calls to next will succeed or fail depending upon the timing of the request.

[rauschma]

@domenic: that makes sense, thanks!

@zenparsing: interesting example! I’d probably want access to the queue then, to configure how it works. I like how CSP handles this: http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-in-JavaScript