Why Go Lacks a Ternary Operator and How It Affects Code Readability

Many languages provide a ternary conditional operator (e.g., val = trueValue if expr else falseValue in Python, const val = expr ? trueValue : falseValue in JavaScript, and similar forms in C/C++). Go, however, does not have this operator; attempting to write val := expr ? "trueValue" : "falseValue" results in the compiler error invalid character U+003F '?' because ? is not a recognized token.

The Go language designers explain that they have seen the ternary operator used excessively to create opaque, hard‑to‑read expressions. Although the if‑else form is longer, it is unquestionably clearer, and a language needs only one conditional control‑flow construct.

To illustrate the impact, the article converts several ternary examples into equivalent if‑else statements. A simple case becomes:

let status = ''
if (type === 1) {
    if (again === 1) {
        status = '再售'
    } else {
        status = '已售'
    }
} else {
    status = '未售'
}

A more complex nested ternary is expanded into a series of if‑else blocks, showing that the resulting code can be difficult to follow, especially when indentation is poor.

The article then argues that for short expressions the ternary form can be more expressive, for example:

const val = expr ? trueValue : falseValue
const func = (age) => age > 18 ? '成年人' : '未成年人'

Such concise conditional assignments appear frequently in development, and the ternary syntax makes the intent clearer than an equivalent if‑else block.

Go’s design philosophy of "simplicity" discourages adding new syntax that can be expressed with existing constructs. Introducing a ternary operator would increase compiler complexity without providing sufficient benefit.

For developers who still want a ternary‑like feature, the article shows a custom generic function:

func If(cond bool, a, b interface{}) interface{} {
    if cond {
        return a
    }
    return b
}

age := 20
val := If(age > 18, "成年人", "未成年人").(string)

However, this approach is not recommended because it incurs performance overhead from using interfaces, requires explicit type assertions, and evaluates all arguments eagerly, unlike the short‑circuit behavior of a true ternary operator.

Finally, the article lists the advantages of the ternary operator—concise expression of simple assignments, reduced intermediate state, and fewer side effects—alongside its disadvantages—poor readability for complex logic, potential for misuse, and the limitation that each branch must be a single expression.