In Go, what does `return 5` compile to in a function with deferred calls and a named result?

## `return` is three things Go's specification describes a return in a function with deferred calls as a sequence, and the compiler implements exactly that sequence: 1. **Assign the returned expressions to the result parameters.** Every Go function has storage for its results, whether or not you gave those results names. `return 5` writes 5 there. 2. **Run the deferred calls for this frame**, last registered first. 3. **Return to the caller**, which reads the result storage. Step 2 sitting between steps 1 and 3 is the entire mechanism behind "a deferred function can change the return value". Nothing magic is happening: the deferred call runs while the frame and its result storage are still alive, and if it can name that storage, it can write to it. ## Named versus unnamed results The only difference between a named and an unnamed result is whether the result storage has an identifier that code inside the function body can refer to. ```go func f() (n int) { defer func() { n++ }() return 5 } // f() == 6 ``` Here `n` *is* the result slot. `return 5` sets it to 5, the deferred closure increments it to 6, and the caller reads 6. ```go func g() int { n := 5 defer func() { n++ }() return n } // g() == 5 ``` Here `n` is an ordinary local variable and the result slot is anonymous. `return n` copies 5 out of `n` into that anonymous slot, and only then does the deferred closure run and bump the local to 6. The caller still reads the copy, which is 5. The closure did exactly what it said; it just wrote to the wrong storage. Spelling the two out side by side is the fastest way to show an interviewer that you understand the *sequence* rather than a rule you memorised. ## A bare `return` with named results A naked `return` in a function with named results skips step 1's copy — the slots already hold whatever the body last assigned to them — and goes straight to running defers and returning. This is why a naked return plus a deferred mutation reads confusingly: nothing in the `return` statement mentions the value the caller gets. Most style guidance restricts naked returns to very short functions for exactly that reason. ## The closure has to be a closure A subtlety that catches people: a deferred call's *arguments* are evaluated at the `defer` statement, so `defer report(n)` captures the value of `n` as it was then and cannot influence the result. Only a closure that refers to the named result by name — `defer func() { n++ }()` — reads and writes the live slot at the moment the defers run. "Pass it as an argument" and "capture it in a closure" look similar in source and behave completely differently here. ## Multiple deferred calls All of the frame's deferred calls run during step 2, in reverse registration order, and each one sees whatever the previous ones left in the result slots. So two deferred closures that both modify a named result compose, with the *last registered* getting first look and the *first registered* having the final word. If you find yourself relying on that ordering to compute a return value, the function is usually asking to be restructured. ## Why this exists at all The design gives Go a place to run code that both observes and adjusts a function's outcome, without adding a language construct for it. Post-processing a result, adjusting a value on the way out, or attaching context to what the function is about to return all become ordinary deferred closures over a named result. The cost is that a reader has to know the three-step sequence to predict what a function returns — which is precisely why it is a standard interview question. ## The one-line summary to say out loud "`return x` assigns to the result slot, *then* runs the defers, *then* returns. If the result has a name, a deferred closure can still change what the caller sees; if it does not, the value was already copied out of reach."