Why does Go have no ternary operator, and what do you write instead?

## The absence Go has no conditional expression. There is no `cond ? a : b`, and there is no `if` that yields a value the way an expression-oriented language's `if` does. Every conditional in Go is a **statement**: it performs effects, it does not produce a value. ## The stated reason The Go FAQ answers this directly: the operator was left out because the designers had seen it used too often to create impenetrably complex expressions. `?:` composes with itself. `a ? b : c ? d : e ? f : g` is legal in the languages that have it, and it appears in real code. An `if`/`else` chain does not compress that way — the syntax forces the branches onto their own lines, where a reader and a diff can see them. This is the same instinct behind Go's other omissions: the language prefers a construct that is slightly verbose but has exactly one reading over a construct that is terse and has several. The cost is paid by the writer, once; the benefit is collected by every later reader. ## What you write instead The standard shape is declare-then-override: ```go limit := defaultLimit if userLimit > 0 { limit = userLimit } ``` Or the symmetric form when neither branch is a natural default: ```go var scheme string if secure { scheme = "https" } else { scheme = "http" } ``` Five lines where another language writes one. In exchange, the two branches are both visible, both greppable, and either one can grow a second statement without a rewrite. ## The builtins that absorb the common case Go 1.21 added `min` and `max` as builtins over any ordered type, and they retire a large share of real-world ternaries: ```go pageSize := min(requested, 500) ``` Before 1.21 that needed a three-line `if` or a hand-written helper per type. Note that `math.Min` and `math.Max` are *not* the same thing — they are `float64`-only functions that predate the builtins, and routing integers through them means two conversions and a loss of precision above 2^53. For integers, use the builtins. ## Where the absence actually hurts Three places, all of them expression positions: 1. **Struct literals and argument lists.** You cannot pick a field value conditionally inside the literal; you compute it into a variable on the line above. 2. **Constant declarations.** A `const` cannot branch at all, so a value that depends on a condition simply cannot be a constant — it becomes a `var` or a function. 3. **Long chains of small choices.** Building a config struct where six fields each have a fallback turns into six three-line blocks. This is the case where people reach for a helper. ## Why a generic helper is not the answer Since Go 1.18 you *can* write one: ```go func pick[T any](cond bool, a, b T) T { if cond { return a } return b } ``` It compiles, and the community still does not use it, for a concrete reason rather than a stylistic one: **Go evaluates all arguments before the call**. `pick(p != nil, p.Name, "anonymous")` dereferences `p` unconditionally and panics, where the equivalent `if` would not. The same eagerness means both an expensive computation and a side effect in the losing branch still run. A ternary in a language that has one short-circuits; a function call cannot. If you introduce such a helper, restrict it to cheap, side-effect-free, already-computed values, and expect a reviewer to push back. ## How to answer the "but it's more verbose" objection The honest answer is: yes, and the trade was made on purpose. Go accepts extra lines to buy a single reading of every branch. The same trade shows up in the absence of implicit numeric conversion and in errors being returned rather than thrown. Someone onboarding from a ternary-rich language should hear that framing rather than a claim that the `if` form is somehow better in isolation — it isn't, it's just harder to abuse.