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:
Both Tokio and futures-rs provide a
selectmacro, 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:
raceandcompletemacros, or other alternatives)?selectwith 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 forFusedFutureto exist at all.Previous discussion: