Why does `break` inside a switch that sits in a Go for loop not exit the loop, and what does?

## What `break` binds to A bare `break` terminates the **innermost enclosing** `for` or `switch` (or `select`) statement — whichever one encloses it most tightly. That rule is short, but its consequence catches nearly everyone once: ``` for _, tok := range tokens { switch tok.Kind { case kindEOF: break // ends the switch, not the loop } emit(tok) } ``` The `break` ends the `switch`. Control lands on `emit(tok)`, the loop runs its next iteration, and the program keeps scanning past the end token. Nothing is reported: the code compiles, and it does something reasonable-looking that is not what the author meant. This is not unique to Go — the same rule holds in C and Java — but Go programs hit it more often because the expressionless switch and the multi-value case make switches inside loops a natural way to write a scanner or dispatcher, and because Go has no `break` needed at the end of each clause, so the one `break` you *do* write looks unusually significant. ## Labels The fix is a labeled statement. A label is an identifier followed by a colon, written immediately before the statement it names, and `gofmt` outdents it one level: ``` Scan: for _, tok := range tokens { switch tok.Kind { case kindEOF: break Scan // terminates the for loop } emit(tok) } ``` `break Scan` terminates the statement the label names. The label of a `break` must name an enclosing `for`, `switch` or `select` — you may label a switch and break out of it from a nested block, though that is rare. The label of a `continue` must name an enclosing **`for`** statement; anything else is a compile error. Three properties of labels are worth knowing: - **Their scope is the function body** in which they are declared, and it **excludes the body of any nested function literal**. You cannot write `break Scan` inside a closure defined in the loop, even lexically inside the labeled loop — the compiler rejects the reference. A callback has to signal its caller instead, by returning a value the loop inspects. - **They live in their own namespace.** A label named `Scan` does not collide with a variable named `Scan`, so labels are conventionally capitalised without any exported meaning. - **An unused label is a compile-time error**, not a warning. If you delete the jump but leave the label, the build fails. That is deliberate: a leftover label usually means control flow was edited and the code no longer does what its shape suggests. ## `continue` does not have this problem `continue` has no relationship with `switch` at all — it applies to the innermost enclosing `for`. So inside a switch inside a loop, a bare `continue` starts the next iteration of that loop, which is usually exactly what you want, and writing `continue Scan` for the immediately enclosing loop is redundant. A labeled `continue` earns its keep only with **nested loops**, where you want the next iteration of the outer one: ``` Outer: for _, file := range files { for _, line := range file.Lines { if line.Broken { continue Outer // next file, not next line } } } ``` ## The alternatives, and when to prefer them A labeled break is not the only way out, and the three options rank differently in review: 1. **Extract the loop into its own function and `return`.** Usually the best answer. The exit condition becomes a returned value or error, the nesting drops a level, and the loop becomes independently testable. If the loop body is doing enough work to need a switch, it is often doing enough to be a function. 2. **Label the loop and `break Label`.** Correct, explicit, and checked by the compiler — the label must name a real enclosing loop, and it cannot be dangling. Right when extraction would mean threading four locals through a parameter list. 3. **Set a boolean flag in the case and test it after the switch.** The worst of the three. It adds state, it delays the exit by the rest of the body, and a later editor who inserts code between the switch and the test introduces a bug that no tool will find. In a review, a labeled break in a two-level loop is fine. A function with three labels is a signal that the control flow wants restructuring rather than more labels. ## Summary `break` binds to the innermost `for` or `switch`; inside a case that is the switch. Label the `for` and use `break Label` to leave it. `continue` already targets the loop, and needs a label only to reach an outer one. Labels are function-scoped, invisible inside closures, and unused ones fail the build.