I like reverse pipes, and they were suggested as an area of exploration back in the early pipeline days. That said, I don't think that is readable in the more common cases, as examples like these often focus on unary functions, but that's rarely the predominant use case. What you would actually see is something like:

const index =
  route("/api/foo")(^^) <|
  authorized("Administrator")(^^) <|
  originCheck(^^) <|
  rateLimited(5, 1)(^^) <|
  function () {};

You most likely need to use double invocation here if you want to reuse existing decorators (despite those decorators needing to be even more defensive around the missing 2nd argument).

Reading through this, I’m a little surprised that we’re considering making async iterables support unordered buffering. But it’s an exciting capability. It might be especially useful when combining WHATWG Streams.

I feel that the default behavior of AsyncIterators, including AsyncIterators created from arrays of promises, should wait for each promise sequentially, like how for await (and Array.fromAsync) already do. The contract of async iterators implies stable sequentiality to me. I don’t know how strongly I feel about this.

I think that using a Rust-like bufferUnordered method is a good idea. It would make developers opt into unordered buffering. (I also slightly prefer bufferUnordered to buffered to clearly indicate the lack of stable order.) I don’t know how I feel about forEachConcurrent and findConcurrent.

Would bufferUnordered return an AsyncIterator that is indistinguishable from other AsyncIterators? Or would it return a new async-iterable type, like Rust’s BufferUnordered class?

A quick note regarding reusing a punctuator in place of void for discards. There are very few of these that are viable due to compound assignment:

// these are all already legal:
using *= f();
using /= f();
using %= f();
using += f();
using -= f();
using &= f();
using ^= f();
using |= f();

jschoi: re:

I feel that the default behavior of AsyncIterators, including AsyncIterators created from arrays of promises, should wait for each promise sequentially

So, an async iterator doesn't actually do anything itself. It doesn't really make sense to compare the behavior of async iterators to the behavior of for await, because the iterator doesn't have any behavior on its own (buffer excepted).

Instead of talking about the behavior of an async iterator itself, we can talk about the behavior observed by consumers of an async iterator. A consumer like for await will see the same thing in all worlds discussed here (unless one is using the new buffering helpers), because for await waits for each promise to settle before pulling the next one, and so could not possibly observe promises settling out of order. The "can things settle out of order" question does not affect such consumers at all.

If we allow settling out of order, that would only be observable to consumers which do multiple calls of .next(). There's nothing in the language that does that right now, but you could do it yourself, in principle. Or, as proposed, you could do it with buffer or bufferUnordered (which would do multiple calls to .next() under the hood). With buffer, if you pull from it the way for await does, you would never see things happening out of order. So the only places this "settling out of order" behavior would be observable would be when manually calling .next() multiple times, or when using bufferUnordered.

Would bufferUnordered return an AsyncIterator that is indistinguishable from other AsyncIterators? Or would it return a new async-iterable type, like Rust’s BufferUnordered class?

First thing. The return value of all helpers would just be instances of AsyncIteratorHelper.

The framing here, from the perspective of the AsyncIterator consumer, makes sense. Promises’ settling out of order is unobservable by default to “higher-level” consumers like for await or AsyncIterator methods (higher-level = “do not directly call .next()).

I think it’d be good to put something like the explanation here into your Gist or your future explainer.