In Go, when are the function value and arguments of go f(x) evaluated?

## The rule, stated precisely A `go` statement has two halves, and they run in different goroutines: 1. **Evaluation** of the function value, the receiver (for a method call) and every argument — this happens *in the calling goroutine*, at the moment the `go` statement executes, in the ordinary left-to-right order. 2. **Invocation** — this happens in the new goroutine, at some unspecified later point. So `go` behaves like an ordinary call right up to the instant of calling, then diverges. ## Passing versus capturing This is the distinction the rule exists to make: ```go h := hosts[0] go check(h) // h is read now; the goroutine gets a copy of that value h = hosts[1] // cannot change the call above go func() { check(h) }() // h is read when this goroutine runs h = hosts[2] // the goroutine may see hosts[1] or hosts[2] ``` The first form **snapshots**. The second form **captures the variable**: a function literal closes over `h` itself, not over its value at the time the literal was written, so it reads whatever `h` holds at execution time. And because the goroutine's read and the caller's write are unsynchronised, that second pattern is a genuine data race — run it under the race detector (`go test -race`, `go run -race`) and it reports one. The fix is one of the two obvious shapes: ```go go check(h) // pass it go func(h string) { check(h) }(h) // or pass it into the literal ``` ## The receiver counts too ```go conn := dial(primary) go conn.ping() // conn is evaluated here conn = dial(backup) // ping still runs against the primary connection ``` The method value, including its receiver, is fixed at the `go` statement. If the receiver is a value type, the goroutine gets a copy of it; if it is a pointer, the goroutine holds that pointer and will see later mutations through it. ## Loop variables and Go 1.22 Historically the most famous version of this bug used a loop: ```go for _, h := range hosts { go func() { check(h) }() } ``` Before Go 1.22, `h` was **one variable reused by every iteration**, so all the goroutines closed over the same slot and typically saw the last hostname — or a mix, unpredictably. Since Go 1.22, each iteration of a `for` loop declares fresh loop variables, so each closure captures its own `h` and this exact loop is correct. The capture rule itself did not change: variables declared *outside* the loop, or reassigned inside it, are still shared, and a closure still reads them at execution time. Passing the value as an argument is the version-independent habit, and it reads unambiguously to reviewers who are not sure which Go version a file is built with. ## Why the compiler may move the variable to the heap A variable captured by a closure that a `go` statement starts can outlive the function that declared it, so the compiler cannot leave it on that function's stack. **Escape analysis** decides this at compile time; `go build -gcflags=-m` reports it, with lines such as `moved to heap: h` and `func literal escapes to heap`. That is not a bug to fix — it is the compiler doing what correctness requires — but it is a useful thing to see when you are explaining to someone why the closure form is not merely a style difference. Passing the value as an argument often avoids the capture entirely. ## The interview shape A common exercise: given a short program that starts a goroutine and then reassigns the variable, say what the goroutine observes. The answer is a two-step: *is the value an argument of the `go` statement, or is it captured by a literal?* Arguments are snapshots taken at the statement; captures are reads that happen later. Everything else — loop variables, receivers, method values — follows from that one distinction.