When does Go evaluate the channel and send-value expressions of a `select` statement's cases?

## The rule Go's specification is explicit about this. For all the cases in a select statement, the channel operands of receive operations, and the channel operands and right-hand-side expressions of send statements, are **evaluated exactly once, in source order, upon entering the select statement**. The result is a fixed set of channels to receive from and a fixed set of (channel, value) pairs to send. Only after that does the runtime determine which of those operations can proceed and choose one. So three things happen in order: evaluate every case's expressions, choose one eligible operation, run that one case's body. ## Why it surprises people The mental model most people carry over from `switch` or from `if/else if` is lazy: evaluate a condition, and if it fails, evaluate the next. Select is not lazy. It cannot be — to know which operations are possible it has to know all the channels first, and to offer a send it has to have the value in hand. The visible consequence is that expressions in cases that lose still ran: ```go select { case frames <- nextFrame(): // only reached if the send proceeds case <-redraw: paint() } ``` `nextFrame()` is called every time this select is entered. If the `redraw` case is the one chosen, the frame that `nextFrame()` produced is discarded — and if `nextFrame` advances an animation counter or pops from a buffer, that state change has already happened. The animation skips frames, and it skips them at a rate that depends on how often the other case wins, which makes it look like a timing bug rather than an evaluation-order bug. ## Inside a loop, it is also a cost A for-select loop enters the select on every iteration, so every case's expressions are re-evaluated on every iteration. Anything that allocates, locks, or does I/O in a case expression does so at loop frequency: ```go for { select { case out <- expensive(): // runs every pass case <-done: return } } ``` A benchmark with `-benchmem` on a loop like this shows allocations you cannot find in any case body, because they are not in a body — they are in the case header. ## The fix Hoist. Compute the value before the select and send the variable: ```go for { v, ok := nextFrame() if !ok { return } select { case frames <- v: case <-done: return } } ``` Now the frame is produced once, and if `done` wins, the value is still in `v` — you can decide explicitly whether to drop it, retry it, or hand it back. The general rule of thumb is that a case header should name a channel and, for a send, a value that already exists. Keep calls out of it. The exception is a call that has no side effect and is cheap enough not to matter, but a reviewer cannot tell that by looking, which is itself an argument for hoisting. ## Source order does matter — for exactly this It is tempting to say "source order is meaningless in a select", because it does not affect which ready case is chosen. That is half right. Order determines the sequence in which the case expressions are evaluated, so two case expressions with side effects that depend on each other will observe each other in written order. That is a fragile thing to rely on, but it is defined, and it is the one place order is significant. ## Receive cases too The same rule applies to the channel operand of a receive. `case <-c.Next():` calls `c.Next()` once per entry to the select, and whatever channel it returns is the one this pass waits on. That is why a case expression that manufactures a fresh channel every pass behaves differently from one that reuses a channel stored in a variable: each entry to the select is waiting on a different object, and anything the previous pass had queued on the old one is unreachable.