link parallel async iterator slides

[bakkot]

(Yes, I know this is very late, but since it concerns a stage 3 proposal I can't really defer it.)

[erights]

@bakkot , Wow, this is a great idea! However, process-wise I think it does indeed need to be bumped back to stage 2 to do this. It is not a trivial change.

[bakkot]

@erights Yeah, agreed, and I'm sorry I didn't think this all the way through earlier. I'm hoping we can keep sync helpers at stage 3, since none of this is relevant to them.

[erights]

I am in favor of keeping sync helpers at stage 3.

[zloirock]

(I hope that it will be added as new methods like .mapParallel since for many cases required sequential semantics.)

[bakkot]

@zloirock You will get sequential semantics unless you manually call .next() multiple times without waiting for the previous promise to settle first. In other words, if you want sequential semantics, just consume the promises sequentially. The change I'm proposing is only observably different if you go out of your way to call .next() eagerly.

[zloirock]

Ah, clear. Makes sense. In this case, I don't think that makes sense to bump it back to stage 2.

[bakkot]

Unfortunately, while it's a very minor change for users of the proposal, it's a fairly major change in terms of the specification and implementation, so I think a return to stage 2 is probably warranted. But we'll see what the committee thinks.

[bakkot]

Made an issue so discussion of this change can have a home: tc39/proposal-iterator-helpers#262