What restrictions does Go place on `goto`, and when is it still the right tool?

## Go still has `goto` It is a real keyword, not a reserved-but-unused one. `goto Label` transfers control to the statement carrying `Label:`. What makes it tolerable is that the spec restricts it to jumps the compiler can still reason about, so it cannot produce a variable that is in scope but never initialised, nor land in the middle of a construct that expects to have been entered from the top. ## The three restrictions **1. The label must be in the same function.** A label's scope is the body of the function that declares it, excluding any nested function literal. So you cannot `goto` out of a closure into its enclosing function, and there is no such thing as a cross-function jump. This alone keeps `goto` from being the unstructured jump it is in older languages. **2. You may not jump into a block.** A `goto` outside a block cannot target a label inside it. Landing inside a `for` body, an `if` branch, or a bare `{ ... }` would skip whatever entering that block normally establishes, so the compiler refuses. Jumping *out* of a block to a label in an enclosing one is fine. **3. You may not jump over a variable declaration in scope at the label.** This is the rule that actually bites: ``` if !ok { goto done // error: goto done jumps over declaration of buf } buf := make([]byte, 0, 64) use(buf) done: return ``` At `done`, `buf` is in scope — the code after the label is entitled to read it — but the jump never executed its declaration. Rather than define that hole away, the spec forbids the jump. There are two fixes, and which one you pick is a design decision: **move the declaration above the `goto`**, so the jump no longer skips it, or **wrap the skipped region in its own block** so `buf`'s scope ends before the label. The second is usually the honest one, because it states that the variable belongs to that section only. Backward jumps are legal and are not restricted by rule 3 — going back to an earlier label reaches a point where fewer variables are in scope, not more — though rule 2 still applies: you cannot jump backwards into a block you are outside of. ## Where it is still the right tool Two places, and interviewers are listening for you to name them rather than to say "never". **A single shared tail.** A function with several failure points that must all run the same short unwinding sequence can jump to one `fail:` label instead of repeating it or building a nested-`if` staircase. In Go this is rarer than in C, because `defer` covers most cleanup and multiple returns are idiomatic — but in hot paths where a `defer` is measurable, or where the tail needs to run only on some paths, the label is the clearer expression. **Generated code.** A code generator emitting a state machine does not benefit from structured control flow; it benefits from a direct correspondence between states and labels. The standard library itself uses `goto` in a handful of tight scanners and parsers for exactly this reason. ## Where it is the wrong tool Leaving nested loops. A labeled `break` names the statement it terminates, and the compiler checks that the label really is a loop, so a reader knows precisely where control resumes. A `goto` can land anywhere in the function, so the reader has to go find the label and then work out what is in scope there. Prefer `break Label` for loop exit and reserve `goto` for the shared-tail shape. Also wrong: emulating a loop. `goto` backwards to build iteration is legal and unreadable; `for` exists. ## The review posture Because the honest set of uses is so small, most codebases treat `goto` as something that needs a sentence of justification in the review, not as a banned construct. The compiler's own restrictions mean a `goto` that compiles is at least scope-safe — the risk is readability, not undefined behaviour. What a reviewer should check is whether the same function could have returned early, deferred the cleanup, or extracted the tail into a small helper, because in ordinary application code one of those three is almost always available. ## Summary Same function, no jumping into a block, no skipping an in-scope declaration; backward jumps allowed; keep it for a single shared cleanup tail and for generated code, and use a labeled `break` for nested-loop exit.