Switch and type switch

Canonical guidance

• expression switches compare ordinary values
• type switches inspect the dynamic type of an interface value
• fallthrough is limited and never applies to type switches

Use when

• choosing between if, switch, and type assertions
• reviewing grouped case logic
• diagnosing case duplication or scope issues

Avoid

• using a type switch on non-interface values
• assuming fallthrough carries condition checks forward
• mixing unrelated case logic into one giant switch

Preferred pattern

switch v := anyVal.(type) {
case string:
	return len(v)
case []byte:
	return len(v)
default:
	return 0
}

Anti-pattern

• using fallthrough to fake a multi-condition type switch

Explanation: This is tempting when cases share work, but type switches and expression switches have different rules and fallthrough does not bridge them.

Why

• switch semantics affect control flow, scope, and runtime type handling in one of the most common statement forms