select! is an abstraction which is somewhat similar to
match but operates on streams and futures directly. But it's not without its shortcoming.
select! introduces a two new keywords:
complete . It requires all futures and streams to be manually fused. And has also required changes in
futures that have created deviations from the stdlib, which is a cost in itself.
Please note that the current version of
- is also more powerful than a stream combinator. E.g. it allows to use
Streams sometimes in a
select!, and afterwards directly again.
- and maybe even more importantly: It allows to use an imperative coding style, which can be a lot more familiar to a certain set of people (for example: me)
Therefore the complexity (which the users of
select! barely encounter) is justified.
I share the concern that the dependency on
FusedFuture which is only defined in a non-stable futures-rs version is not ideal. But I think this can be solved without giving up on a powerful
select!. I wrote a proposal on futures-rs for this a while ago - without feedback so far.
And because there's no precedent for including a macro as complex as
select! in the stdlib
Actually I think
select! is not that complicated in what it does.
println! might be on the same level. The question would be more along whether people feel it's mature enough to stabilize it. I would be very reluctant to claim it is, since we are still just starting to work with async/await. I am even not sure for the underlying
FusedFuture - which would be required to move to
core in order to be able to provide
select!able futures in crates which do not depend on a specific
futures-rs version. That was one of the reasons I wrote the linked proposal above, which would also remove the necessity for that.