Is the Go Ternary Operator War Finally Over? Go Bible Author Proposes a Compromise

For years the Go community has repeatedly raised the lack of a ternary conditional operator—familiar syntax in C, Java, and JavaScript—as a missing feature, filing proposals from Issue #23248 through #78865 with extensive data and real‑world examples.

Why a simple assignment feels cumbersome in Go

A typical case shows a developer needing to assign a string based on a boolean:

var priority string
if t.Urgent {
    priority = "high"
} else {
    priority = "normal"
}

In languages with a ternary operator this would be a one‑liner: priority = t.Urgent ? "high" : "normal". The Go version forces a five‑line if‑else block, which many consider a design flaw.

A static‑analysis tool scanning top‑level projects such as golang/go, kubernetes, and terraform found that roughly one in every six to seven functions contains this “verbose” pattern.

Core team's "iron wall": fear of nested hell

In the response to Issue #33171 the Go core team, led by Ian Lance Taylor, cited a fear of “nested hell”. They argue that ternary expressions can become unreadable when nested, as illustrated by a C‑style nested conditional:

result := a > b ? a > c ? "a" : c > b ? "c" : "b" : b > c ? "b" : "c"

Go deliberately requires if‑else statements to use braces, preventing the classic “dangling else” ambiguity of C. Their philosophy is to prefer a few extra lines of clear code over a compact but potentially confusing expression.

Community pushback

“The risk of unreadable code stems from nesting, not the ternary operator itself. Why trust developers not to abuse if but distrust them with ?: ?”

Some contributors suggest using go vet or linters to ban nested ternary forms while allowing simple flat expressions, pointing to mature best‑practice guidelines in Java and C++.

Donovan's compromise proposal (Issue #78940)

Alan Donovan, co‑author of "The Go Programming Language", introduced a new syntax that treats the construct as an expression rather than a statement: (if cond then expr else expr) Key features of the proposal:

It is an expression , allowing direct assignment, e.g. role := (if isAdmin then "admin" else "user").

Parentheses () are mandatory, reinforcing Go’s explicitness and eliminating ambiguous nesting.

A new keyword then (or ? as an alternative) distinguishes the construct from ordinary if‑else statements.

The design aims to balance “concise expressiveness” with Go’s commitment to readability and the avoidance of “black‑magic” code.

Current status and outlook

The proposal has been formally submitted and reignited discussion. Opinions are split: some praise its elegance, while others worry that introducing the then keyword adds unnecessary complexity compared to the traditional ?: operator.

Regardless of the outcome, the debate illustrates how Go’s evolution is shaped by ongoing dialogue between the core team and its community, emphasizing minimization of cognitive load over sheer line count.