Marcel Laverdet

@aBurmeseDev @kume @RanVaknin please let me know if you need any more information on this.

@conartist6 this implementation does not forward terminations correctly. See: ```js import { asyncInterleaveReady } from "iter-tools"; async function* range(count) { console.log("start"); try { for (let ii = 0; ii <...

This is the one we use. It avoids the race leak and terminates on closure. Not sure if a fast iterable will starve the others, that wasn't a design goal....

Oh yeah, and I believe that all implementations shared here don't fire off a next() call immediately after the previous result resolves. What we're all doing is buffering 1 result...

Hello. I'd like to point out that `bufferAhead` as implemented in iter-tools could be considered an unsafe operation. The problem that I have with it is that it consumes values...

> Why does it wait for the previous call to iterator.next() to settle before calling iterator.next() again, though? Well, I think calling .next() concurrently is a mistake and I would...

Well a big difference between `bufferAhead` and `Promise.all` is that `bufferAhead` is creating these promises on the developer's behalf whereas `Promise.all` accepts a vector of promises which are already created....

> It gets you the ability to specify an async iterator which can be consumed concurrently, at the consumer's option. I am open to other ways of accomplishing this but...

Could `bufferAhead` pass along information in the derived iterable which is used to signal ahead that the iterable is concurrent? Something like `{ [Symbol.asyncConcurrency]: 3, next() { ... } }`....

Good luck! This proposal is deceivingly challenging. I still think that `buffered` is a flawed primitive in that it conflates concurrency of a mapping function with concurrency of the underlying...