[tapirl]

Equality is meaningful only if at least two case operations are always non-blocking. This is rare in practice.

In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.

[lanstin]

As far as priority goes, most interesting cases will have priority based on the data in the read, except for this specific case of a done chan el and a data channel. I used that pattern at first but have been moving away from it. To be sure i am mostly writing long lived processes with fixed pools of worker go routines and either never exit or exit based on WaitGroups determining the work is all done.

[tapirl]

Yes, it (the lack of deterministic-select) is only annoying for several special cases. For most cases, it doesn't matter whether or not the default behavior is deterministic.

[lanstin]

Wouldn't it be the case id one worker was pulling work asynchronously delivered from two places? I only use one go routine / one channel myself, but the name select itself very strongly implies it is a yield type operation where any of a number of async actions can wake it for their callback to run. Albeit without a callback syntax, it is async and better be fair.