Provide alternative precedences for select!

[gavrie]

The select! macro currently selects a random future in case multiple futures are ready.
It would be useful to be able to specify the precedence, for example choosing the first future like the existing behavior of Select.

This could be implemented by providing a parameter or with a separate wrapper macro such as select_first!.

Of course it's possible to work around this by not using the select! macro or by calling it multiple times, but it seems useful to have.

[seanmonstar]

There is select and selectUnbiased in Kotlin, where the default doesn't use random, and a user opts in explicitly for randomness.

This differs from the current implementation, which I believe chooses to use randomness implicitly following Golang's lead.

(I think I'm in favor of random being opt-in, personally.)

[Matthias247]

I would like to like to see it too! One benefit of that would be also that the unbiased version would work in nostd, due to not having a dependency on a random generator.

Regarding what the default should be, I am undecided:

• I understand Go opting for randomizing as a default since it avoids starvation/deadlocks if the same path is always ready. The unbiased method requires users to understand that.
• However it's often helpful being able to be able to specify priorities. E.g. a result always having a higher priority then a timeout. Or a value from one channnel (e.g. the control channel) being more important than from another one (the data channel). I think some people even expect the order to reflect priorities when they write their code. The non randomized version will also perform slightly better.

In the current state maybe adding a select_biased/select_with_priority macro might be the favorable option for purely the reason that it won't break existing code.

[mzabaluev]

Would it make sense to have a macro for equal priority round robin polling? Like stream::Select, but for a small static set of streams which may be optimized better than SelectAll: a u32 value is enough to hold the round robin index and closed state flags for up to 27 streams.

[mzabaluev]

better than SelectAll

It would also allow constituents of different types and do not require Unpin.