switch Statements

A status-code handler grows one branch at a time — if code == 200 … else if code == 404 … — until the test function is a hundred lines of chained comparisons repeating the same value. The switch exists to say: evaluate this once, then pick the matching case.

func classify(code int) string {
	switch code {
	case 200, 201, 204:
		return "success"
	case 400, 403:
		return "client error"
	case 404:
		return "not found"
	case 500, 502, 503:
		return "server error"
	default:
		return "unknown"
	}
}

Four properties are worth stating precisely, because each one is a difference from the switch you may have met elsewhere — and from the if/else chain it replaces:

The tag is evaluated exactly once. switch code computes the value, then compares it down the case list. You may also omit the tag entirely and compare each case against true — the form in the next chapter — but whether tagged or not, there is one evaluation, not one per branch.

Cases need not be constants. C demands constant integer labels; Go compares arbitrary expressions of a matching type:

switch time.Now().Weekday() {
case time.Saturday, time.Sunday:
	// weekend — time.Saturday is a constant, but the tag could be anything
}

Anything comparable works as a case value — strings, runes, enumerated types — as long as each case expression has the same type as the tag (the same comparability rules from Operators and Expressions apply: no slices, no maps).

There is no implicit fallthrough. Execution enters the matching case and leaves the switch at its end, even when that case's body is empty. An empty case 3: does not mean "also 3" — grouping is spelled with commas: case 1, 2, 3:. This single rule removes the most common switch bug in other languages, where a forgotten break silently runs the next branch's code.

default is optional and can sit anywhere. Convention puts it last so the eye reads specific-to-general, but the compiler accepts it first or in the middle — and switch with no matching case and no default simply does nothing, so a dispatch that must handle every value either carries a default or is checked by the compiler through exhaustiveness elsewhere.

The form to reach for whenever three or more branches dispatch on one value: one evaluation, one list, one place to add the next case. The chains it replaces in Conditionals with if and else were readable at two branches; at five they were a pyramid.

Sometimes there is no single value to dispatch on — each branch tests a different condition:

switch {
case n < 0:
	return "negative"
case n == 0:
	return "zero"
case n < 100:
	return "small"
default:
	return "large"
}

An omitted tag is switch true, which turns every case into a condition checked in order until one is true. Functionally this is an else-if chain; the difference is optical and practical: the conditions line up in one column at one indentation level, each reads as an independent rule, and there is no else { if { else { stairway to maintain.

Ordering is now load-bearing, and the mental model is first-match-wins: cases run top to bottom, and as soon as one evaluates true the rest are never examined. The example above works only because the ranges are mutually exclusive; overlapping conditions hide behind whichever comes first:

switch {
case n < 100:      // catches 0 too — 'case n == 0' below is dead
	return "small"
case n == 0:
	return "zero"   // unreachable for n < 100
}

When a rewrite of one rule breaks an unrelated case, that is the signal the conditions are ordered wrong or should be written as a single explicit predicate per branch. Unlike a value switch, none of these expressions share a type constraint — each is its own boolean — and none need be constant.

The judgment call between forms:

One performance note for the record: do not "optimize" a value switch into an if-chain by hand. The compiler already treats dense integer case lists as a dispatch structure — a jump table rather than a sequential compare — so the readable form is also the fast form. Reach for switch true as a restructuring of logic, and the tagged switch as your default dispatch; both keep the control flow declarative enough that a reader sees the rules rather than the plumbing.

Every rule in this topic so far has been about not running adjacent code. fallthrough is the deliberate exception: it transfers control to the next case's body without evaluating that case's expression.

switch level {
case "info":
	logInfo(msg)
	fallthrough
case "debug":
	logDebug(msg)   // runs for "info" AND "debug"
case "trace":
	logTrace(msg)   // only for "trace" — no fallthrough above it
}

Read it as "and also do the next thing": an info entry logs info, then unconditionally executes the debug body even though the tag never matched "debug". The expression is skipped entirely — fallthrough is a jump, not a comparison — which means case bodies in a fallthrough chain must be written to tolerate being entered from above.

Three restrictions keep it contained. It must be the final statement of its case (statements after it are unreachable). It is illegal in the last case — there is no next body to enter, and the compiler says so. And it is forbidden in type switches, where cases name types rather than values and "the next type" has no coherent meaning.

Notice what fallthrough is not: it is not how you group values. For shared bodies, case 1, 2, 3: is the tool — comma-separated expressions entering one body — and most codebases contain zero fallthroughs because grouping plus well-named helpers covers the legitimate cases. When you do see one, it should read as an intentional cascade (the log-level example above), not as a substitute for a missing comma.

The other switch Go ships works on a different axis entirely. Instead of comparing the tag against values, a type switch asks what dynamic type an interface value currently holds:

switch v := value.(type) {
case int:
	fmt.Println("int:", v*2)      // v is bound to the int in this branch
case string:
	fmt.Println("string:", v)
default:
	fmt.Printf("other %T\n", v)
}

Each case is a type, v is re-declared per branch with that branch's type, and there is no fallthrough because branches are disjoint by construction. That is dispatch on what a value is rather than what it equals — the type-assertion machinery from Type Assertions and Type Switches in statement form, and the natural successor to this topic once values-and-conditions dispatch is automatic. With branching and dispatch settled, the last piece of control flow is repetition — Go's one loop keyword, in Loops with for.