Which evaluation orders does the Go spec guarantee inside one expression, and which are left unspecified?

## Precedence is not evaluation order Precedence decides how an expression *parses* — which operand belongs to which operator. Evaluation order decides *when each subexpression actually runs*. They are independent, and Go pins down much less of the second than people assume. ## What Go actually guarantees Within a function, when evaluating the operands of an expression, assignment or return statement, the spec orders exactly four kinds of thing, in lexical left-to-right order: - function calls - method calls - receive operations on a channel - binary logical operations, that is `&&` and `||` That last item is the short-circuit guarantee. `a() && b()` always evaluates `a()` first and only calls `b()` if `a()` returned true. Go has no non-short-circuiting boolean operator at all — `&` and `|` are defined on integers, not on `bool` — so there is no way to accidentally force both sides, and no need for the "use `&` when you want both evaluated" habit some languages carry. At package level the rule is different: initialisation dependencies decide the order of variable initialisation expressions, and only expressions with no dependency relation fall back on declaration order. ## What Go deliberately leaves unspecified Everything else. The relative order of a call and a plain operand next to it is not defined: ```go a := 1 f := func() int { a++; return a } v := []int{a, f()} // may be [1 2] or [2 2]; both conform ``` The spec's own example goes further: in `y[f()], ok = g(z || h(), i()+x[j()], <-c), k()` the *calls and the receive* are ordered `f()`, `h()` (only if `z` is false), `i()`, `j()`, `<-c`, `g()`, `k()` — but when the indexing of `x`, the evaluation of `y`, and the read of `z` happen relative to those is not specified. This is a design choice, not an oversight. Fully ordering every operand would constrain the compiler's freedom to reorder loads for no user-visible benefit, and Go's answer is that any expression whose result depends on that ordering is a bug in the program, not a question for the language. ## The two-phase assignment rule Assignment is specified more tightly, and this is the part that shows up in interviews. It proceeds in two phases: 1. **Phase one:** the operands of index expressions and pointer indirections on the **left**, together with all the expressions on the **right**, are evaluated. 2. **Phase two:** the assignments are carried out left to right. Three consequences: ```go a, b = b, a // a real swap: both right-hand values are read in phase one x := []int{1, 2, 3} i := 0 i, x[i] = 1, 2 // i becomes 1, and x[0] becomes 2 - the index used the OLD i x[0], x[0] = 1, 2 // phase two runs left to right, so x[0] ends up 2 ``` The swap is the friendly face of the rule and the `i, x[i]` case is the sharp one. The index operand `i` on the left is evaluated in phase one, while `i` still holds 0, even though the assignment to `i` is listed first. ## Why this matters in production The failure mode is a flaky build. Code whose result depends on unspecified order is not *wrong* on any given run — it is wrong only sometimes, and "sometimes" is decided by the compiler version, the target architecture, the optimisation the inliner happened to make, or whether the race detector build shifted things around. A test that passes on your laptop and fails one CI run in twenty, in a package with no goroutines in it at all, is the shape this takes. Three habits keep you out of it: - **One side effect per statement.** If a function mutates something another operand reads, give it its own line and a name. The extra local costs nothing and makes the order explicit. - **Do not rely on `go vet` here.** Vet catches many things; "this expression depends on unspecified evaluation order" is not generally one of them. The compiler will not warn either, because the program is legal. - **Read assignments with the two-phase rule in mind** when an index or a pointer appears on the left and the same variable appears on the right. ## What to say when asked Name the four guaranteed-ordered constructs, say that everything else is unspecified, and then give the two concrete demonstrations: `[]int{a, f()}` for the unspecified part and `i, x[i] = 1, 2` for the two-phase assignment. Finish with the practical rule — if you had to think about the order, split the statement — which is the answer an interviewer is actually looking for.