How can a deferred closure change the value a Go function has already returned?

## The three-step return The key is that a `return` statement in Go is not atomic. Executing `return x` does three things, in order: 1. assign `x` to the function's **result variables**; 2. run every pending deferred call for that function, newest first; 3. transfer control back to the caller, with whatever the result variables now hold. Step 2 sits *between* the assignment and the hand-off. That gap is the whole mechanism. ## Named results give the gap a handle Declaring results with names — `func f() (n int, ok bool)` — creates ordinary variables, initialised to their zero values at function entry and living for the whole call. A deferred closure can read and assign them like any other variable in scope: ```go func plusOne() (n int) { defer func() { n++ }() return 5 // assigns n = 5, runs the defer (n becomes 6), returns 6 } ``` The caller receives `6`. Nothing about the `return 5` line suggests that, which is exactly why interviewers like the question: it tests whether you know what `return` really does. With unnamed results there is no variable to touch: ```go func unchanged() int { n := 5 defer func() { n++ }() return n // returns 5 } ``` Here `n` is a local. `return n` copies its value into the function's anonymous result slot, and the deferred closure then increments the local — too late, and against the wrong thing. The caller gets `5`. Placing these two functions side by side is the clearest way to explain the rule. ## The closure has to do the read and the write Two details decide whether the trick actually works. First, it must be a **closure with no parameters** (or at least, the result must not be passed in). `defer adjust(n)` evaluates `n` at the `defer` line — before `return 5` has even run, so it captures the zero value and cannot write back. `defer func() { n++ }()` runs its body at return and touches the live variable. Second, the deferred call must belong to **this** function. A closure deferred inside a nested function literal adjusts that inner function's results, not the outer one's. A bare `return` in a function with named results returns whatever the named variables currently hold — the naked-return form. It is the same mechanism seen from the other side, and it is why some codebases restrict naked returns: the value that leaves the function is no longer visible on the `return` line. ## What it is good for, and what it costs The honest use is **post-processing a result on every exit path**, without repeating the logic at each `return`. A function with six returns can adjust, annotate or record its outcome once, in one deferred closure, and be sure no path escapes it. That is a real benefit: the alternative is six edits that a future contributor will make five of. The cost is readability. A reader looking at `return 5` has to notice a `defer` fifty lines above to know the caller gets `6`. The convention that keeps it manageable: the deferred closure that mutates a named result goes at the very **top** of the function, immediately after the results are declared, so the reader meets it before any `return`. And name the results meaningfully — `(n int)` is fine, `(result int)` on a function whose result is never adjusted is just noise. ## Interaction with the rest of `defer` Multiple deferred closures that touch the same named result run last-in-first-out, so the last one registered sees the value the ones after it produced — order matters, and stacking two mutators on one result is usually a sign the logic wants to be a plain helper instead. And because deferred calls run on every exit path, a mutator registered at the top applies to the guard-clause return in line three just as much as to the happy path at the bottom. That universality is the point; it is also what makes an accidental mutation so hard to spot. ## How to answer it Say the three steps of `return` out loud, then show the two-function contrast: named result gets `6`, unnamed local gets `5`. If pushed, add the argument-evaluation detail — passing the result to the deferred call captures a copy at the `defer` line and defeats the whole thing.