Kevin Gibbons

That eagerly consumes all the values from the underlying iterators, regardless of how fast the consumer is reading them. The point of this is to produce values only as fast...

> Always setting a limit would also help to maintain a nice and appropriate backpressure. If you create an iterator with a `.buffer(2)` limit, you would hope that this cannot...

> Now there might be a way to run an async iterator faster than it will be consumed I'm not sure what this means. An iterator can't produce values which...

> The mapping functions may inadvertently rely on not being invoked concurrently. I agree that in this situation you shouldn't invoke the mapping functions concurrently, but I don't think we...

@laverdet I'm not sure what you mean by "unsafe" or "ownership" here. I think it's expected when buffering that results are produced in advance of being consumed, such that if...

That said, I do think the `divide` helper you give is interesting as a way to split up work. Why does it wait for the previous call to `iterator.next()` to...

I agree that using these APIs in situations where you need to dispose of values explicitly would be bad. But I am reluctant to optimize for that (in my experience)...

> Nothing stops the developer from doing: `Promise.allSettled(promises).then(reportDiagnostics); return Promise.all(promises);`. On the other hand the exact errors lost by `bufferAhead` are gone without some fancy buffering before that stage of...

> So instead of dropping a `.bufferAhead(4)` at the end of the pipeline I would rather have `makeProducer(4)` and let this factory apply the desired concurrency when possible. The whole...

> I do kind of want an eager mode. One could also imagine a `earlyStart` that just pre-reads the first element, right away, specifically for use with `bufferAhead`, but it...