select macro

[nrc]

Both Tokio and futures-rs provide a select macro, they provide roughly the same functionality but have different implementations, APIs (in the mini-language supported), and constraints (notably, futures-rs requires futures to be fused).

There seems to be a lot of demand for select (and it is runtime-agnostic), so it is a good candidate for inclusion in std, rather than it being supplied with a runtime. However, there seem to be a lot of questions:

• is it the right thing to support at all (c.f., race and complete macros, or other alternatives)?
• should we require fusing futures? (I'm picking up a preference for not (the Tokio approach) but there is some discussion about whether that permits subtle footguns).
• There may be questions about the interaction of select with cancellation. Looking at cancellation again is one of the goals of the ongoing async work (see, roadmap)

Note that since it is a macro, select is likely to be insta-stable. Also note that if we don't require fusing in select, then there is probably no reason for FusedFuture to exist at all.

Previous discussion:

• Tokio PR
• future-rs issue
• user.r-l.o thread
• StackOverflow question

[danielhenrymantilla]

A tiny improvement w.r.t. footguns could be to:

• maybe make the if guard mandatory for non-FusedFutures
• and/or some other way to express the intent that "I, as a user, hereby declare to be the one keeping track of completion". Even something as basic as an #[unfused] annotation or an .unfused() zero-cost adapter, or something along these lines.

[yoshuawuyts]

I wrote an in-depth analysis of select! {} in my "Futures Concurrency III: Select" blog post. To summarize my conclusion: the select! {} is difficult to use, would be hard to bring bring into the stdlib or language, and the same modes of concurrency can be exposed through alternative APIs. The AsyncIterator::merge family of APIs seems like the most promising alternative, and I would recommend we shift our focus to exploring those further instead.