see also recent discussion: https://groups.google.com/g/golang-nuts/c/I9cbvCB86MA/m/GCKIJbzPAAAJ

It seems to me that instead of or one could write

        select {
        case x := <-c1:
            ...
        case x := <-c2:
            ...
        default:
                select {
                        case x := <-c3:
                            ...
                        default:
                            ...
                }
        }

It seems to me that instead of or one could write

        select {
        case x := <-c1:
            ...
        case x := <-c2:
            ...
        default:
                select {
                        case x := <-c3:
                            ...
                        default:
                            ...
                }
        }

@ianlancetaylor

I suppose that if you have a default in your select statement, then these are almost equivalent. But consider the case where you don't want to have a default:

        select {
        case x := <-c1:
            ...
        case x := <-c2:
            ...
        default:
                select {
                        case x := <-c3:
                            ...
                }
        }

If c1 and c2 are empty then we will move on to the next select statement that only waits on c3. If then something comes up on c1, then we won't be reading from that. So the behavior of this construct is different from my suggestion. In my proposal, c1 would still be read from if nothing comes up on c3.

I too would like to see a deterministic select (vs random), at least as an option. Syntax, I'm not married to any particular ideas.

Right now I have this, which .. is on the racey side.

select {
    case x := <-c1:
        ...
        default:
                select {
                        case x := <-c1:
                            ...
                        case x := <-c2:
                            ...
                }
        }
 }

If I don't have C1 immediately ready, and then both C1/C2 show up "simultaneously", it's random which one of C1/C2 will get the flow. And happens enough to make unit tests flakey.

In reality, I'm actually doing 3 channels, with "best effort priority", but the code for that is really nasty. If this, then that. Otherwise, if those, do those. Otherwise, do all 3. With too much duplication, in a loop that's already expensive.

I've also had to learn (and re-learn at least once more) the hard way that selects are non-deterministic. But that's on me, the docs are clear, even when the behavior is non-intuitive.

It seems to me that the ordering of select is not the best way to deal with the ordering of elements. It seems better to create a priority-queued channel intermediary, which is fairly easy to do now that generics are available. For example:

Playground Link

type PriorityChanQueue[T any] struct {
	q   pqueue[T]
	out chan<- T
	add chan item[T]
}

func NewPriorityChanQueue[T any](out chan<- T) *PriorityChanQueue[T] {
	pcq := PriorityChanQueue[T]{
		out: out,
		add: make(chan item[T]),
	}
	go pcq.loop()
	return &pcq
}

func (pcq PriorityChanQueue[T]) Stop() {
	close(pcq.add)
}

func (pcq PriorityChanQueue[T]) Add(p int, v T) {
	pcq.add <- item[T]{p: p, v: v}
}

func (pcq PriorityChanQueue[T]) C(p int, c <-chan T) {
	go func() {
		for v := range c {
			pcq.add <- item[T]{p: p, v: v}
		}
	}()
}

func (pcq *PriorityChanQueue[T]) loop() {
	defer close(pcq.out)

	var out chan<- T
	add := pcq.add
	for {
		select {
		case out <- pcq.q.Peek():
			pcq.q.Pop()
			if len(pcq.q) == 0 {
				if add == nil {
					return
				}
				out = nil
			}

		case v, ok := <-add:
			if !ok {
				add = nil
				continue
			}

			pcq.q.Push(item[T]{p: v.p, v: v.v})
			out = pcq.out
		}
	}
}

Maybe something like this, but with more thought put into it than this really quick example, could be added to x/sync?

If I don't have C1 immediately ready, and then both C1/C2 show up "simultaneously", it's random which one of C1/C2 will get the flow.

I would think that in practice it is extremely unlikely that two different channels could be unblocked literally simultaneously. And even if by shear luck they did, you wouldn't be able to prove it anyway. Consequently, I feel like this aspect of a priority select is ill-defined.

However, defining priority for the initial evaluation of the select cases, instead of simply randomly selecting among the available ones, is well-defined and very useful. As was mentioned, you can more or less get this behavior today with a bunch of selects with default cases, but it is quite cumbersome when you have multiple cases. So it would definitely help to be able to do something like this:

select first {
case <-c1:
   ...
case <-c2:
   ...
case <-c3:
  ...
...
}

I would think that in practice it is extremely unlikely that two different channels could be unblocked literally simultaneously. And even if by shear luck they did, you wouldn't be able to prove it anyway. Consequently, I feel like this aspect of a priority select is ill-defined.

I'm not sure about this. For example, what if you have something like

for {
  select {
  case v := <-highPriority:
    longRunningThing(v)
  case v := <-lowPriority:
    otherLongRunningThing(v)
  }
}

Then several things send to each while one of those long-running things is running. By the time the loop comes around again, even with unbuffered channels, you could easily have multiple things queued up in each channel. In that case, the select will choose one randomly. What this proposal is asking for is the ability to guarantee that highPriority is completely drained before lowPriority.

I still think separate implementation is better, though. For example, if you have a select-like structure that's ordered, how do you tell it to allow stuff through from lowPriority sometimes if it's been blocked on highPriority for a while? With a priority queue, it can be tuned to whatever the client needs at the time, while select, like most language features, probably won't have too many nobs on it.

@DeedleFake Yeah that's falls under the "initial evaluation" I was describing in the second paragraph. What I mean here is that once a select actually blocks the goroutine (meaning that none of the cases were available initially), then it is not really possible for more than one case to unblock simultaneously.

For example, if you have a select-like structure that's ordered, how do you tell it to allow stuff through from lowPriority sometimes if it's been blocked on highPriority for a while? With a priority queue, it can be tuned to whatever the client needs at the time, while select, like most language features, probably won't have too many nobs on it.

If you actually need this level of complexity, then sure. But we generally don't. For example, it's fairly common for newcomers to write something like this:

for {
    select {
    case <-ctx.Done():
        return
    case x := <- c:
        // do something with x
    }
}

But then, there is non-determinism surrounding what happens when the context is canceled when the producer is "chatty". So then they have to rewrite it to this:

for {
    select {
    case <-ctx.Done():
        return
    default:
    }
    select {
    case <-ctx.Done():
        return
    case x := <- c:
        // do something with x
    }
}

Here is an interesting example from Tailscale. This select statement wants to flush if none of the cases are true. This is done by repeating the entire select statement.

https://github.com/tailscale/tailscale/blob/main/derp/derp_server.go#L1374

I don't think this proposal handles this case. Which is not a mark against it. But it would be interesting if we could handle this somehow.

@griesemer points out that a better choice than or would be else, since else is already a keyword.

Based on the discussion above, and the emoji voting, there isn't strong interest in this proposal. It is always possible to write the code that one wants, with some additional verbosity; this proposal just permits some code to be written somewhat more tersely.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.