proposal: Go 2: spec: conditional-assign (?=) for limited ternary operator functionality

[ugorji]

Introduce a ?= operator, to support the limited use-case of a conditional assignment

var s ?= boolean_expr, ifTrueVal, ifFalseVal

For example:

var v, s string
// ...
 s ?= len(v) == 0, "blank", "not blank"

By using commas in the RHS, it limits this syntax to only be usable on explicit assignment to a declared variable and consequently limits the LHS to only have one declared variable.

Also, because go does not permit variable assignment to declare variables on the RHS, this CANNOT be abused.

---

This is not a ternary operator proposal, or contain the drawbacks of it.

I appreciate the resistance to do a ternary operator (see https://golang.org/doc/faq#Does_Go_have_a_ternary_form ), and I have also looked at some proposals and conversations to add it back in some form: (see https://golang.org/issue/20774 )

This is NOT such a proposal.

We all can clearly see the benefit of the ternary operator as seen in (scenario 1) where it translates:

var n T
if expr {
    n = trueVal
} else {
    n = falseVal
}

to a 1-liner

var n = expr ? trueVal : falseVal

The overriding drawback is that it permits the creation of incredibly complex nested expressions as seen in (scenario 2)

var b1, b2, b3 bool

var s = b1 || b2 ? b2 && b3 ? b1 && b3 : "s1" : "s2" : "s3": "s4" // impossible to read

VERSUS

var s string
if b1 || b2 {
    if b2 && b3 {
        if b1 && b3 {
            s = "s4"
        } else {
            s = "s3"
       }
    } else {
        s = "s2"
    }
} else {
    s = "s1"
}

Clearly, it's incredibly hard to understand the one-liner in scenario 2. Its longer version, while many lines, is clearly more readable. I have looked at the one-liner many times, and I don't even know if it is even correct, or if the syntax is correct. Clearly, the one-liner is unreadable, and it was great that it was disallowed in the language.

---

The main drawback occurs only when there is more than 1 boolean expression checked within the RHS. The way to limit it is to make the syntax be tied to the assignment operator, so it can only occur during explicit variable assignment.

We know the common use of ternary operators by pragmatic programmers is scenario 1. What if we can allow that use-case, and just that alone? It could dramatically reduce the number of lines of code. This is what this proposal should permit.

---

Thoughts? Please let us discuss ideas about how this could give us the middle ground we all crave i.e. pragmatically limit the use of ternary operator to the one-line, one expression cases that we all agree improves readability.

^^ cc'ing @agl @rsc @bradfitz @dominikh @robpike @ianlancetaylor

---

Alternative syntax from comments below that I really like:

@nigeltao #31659 (comment)

// boolean expressions and assignment values are simple statements which do not nest
var s string = b1 ? "s1" : b2 ? "s2" : b3 ? "s3" : "s4000"
// equivalent to
if b1 { s = "s1" } else if b2 { s = "s2" } else if b3 { s = "s3" } else { s = "s4000" }

[urandom]

I'd honestly prefer for the if and switch statements to be turned into expressions instead. There are quite a few mainstream languages that either started with these things as expressions or migrated to them, and the syntax will not be confusing for a lot of people.

And something like this would suffice for ternary:

a := if condition {
     trueVal
} else {
     falseVal
}

And of course, if you have a lot of conditions:

a := switch condition {
case A: aVal
case B: bVal
....
case Z: zVal
....
}

[alanfo]

I like this proposal which is simple, clear, generic, backwards-compatible and would cut down on verbosity whilst avoiding the excesses of the C-style ternary operator. It should also be possible to implement it efficiently in the compiler.

In the absence of the ternary operator, I often write a function instead but, lacking generics as well, this isn't a great solution.

I wondered at first whether there might be a case for having a ?:= operator as well so that the variable could be defined on the same line without the need for var. But I think on balance it's best to stick with a single ?= operator and to require the use of var in this scenario as type inference can, of course, still be used.

TBH I'm not a fan of if and switch doubling up as expressions having used them in this guise in Kotlin (which uses when instead of switch). They tend to produce rather untidy code as well as blurring the distinction between statements and expressions which I personally dislike. In fact, this is a very heated topic in the Kotlin community half of which would like to see the ternary operator (or some form of it) introduced whereas the other half prefer the status quo.

[ntrrg]

What about the Python way?

x := "yes" if true else "no"

Some people don't like the ? : sintax

[ugorji]

What about the Python way?

x := "yes" if true else "no"

Some people don't like the ? : sintax

This is not about the ? : syntax at all. This is NOT a proposal to introduce a ternary operator. Please re-read the whole proposal. This is a proposal to allow a conditional assignment to a declared variable, which will accommodate most of the pragmatic use-cases of ternary operator, while bypassing the drawbacks.

If the syntax is available as part of an expression, then it can be misused.

[ugorji]

I'd honestly prefer for the if and switch statements to be turned into expressions instead. There are quite a few mainstream languages that either started with these things as expressions or migrated to them, and the syntax will not be confusing for a lot of people.

And something like this would suffice for ternary:

a := if condition {
     trueVal
} else {
     falseVal
}

And of course, if you have a lot of conditions:

a := switch condition {
case A: aVal
case B: bVal
....
case Z: zVal
....
}

if/switch expressions do not help eliminate the drawbacks. By definition, an expression can be nested, so the drawbacks are there. It is just a different syntax for the ternary operator, with all the drawbacks it has when used as part of an expression.

The reason this proposal can work, is that the operator cannot be part of an expression, as it is an assignment operator, like = or :=, which MUST have exactly one declared variable on the LHS.

[josharian]

MUST have exactly one declared variable on the LHS.

This is necessary to avoid ambiguity with the syntax you chose, but it is a bit unfortunate. Consider (using the python syntax for clarity only):

a, b ?= b, a if swap else a, b

The restriction that does the work “to avoid abuse” is that of being a statement instead of an expression, not of having a single variable on the LHS.

Some other questions and observations.

Can you declare variables this way, using ?:=?

Other syntax in Go like ?= modifies the LHS (+=, <<=, etc.). That makes this a bit of an anomaly.

[ntrrg]

Sorry, I didn't mean you were talking about including the ternary operator, I just was saying that writing:

var s ?= boolean_expr, ifTrueVal, ifFalseVal

Could be easier to read if you write:

var s ?= ifTrueVal if boolean_expr else ifFalseVal

If you see var s ?= boolean_expr, ifTrueVal, ifFalseVal is like writing a boolean_expr ? ifTrueVal : ifFalseVal

[ugorji]

MUST have exactly one declared variable on the LHS.

This is necessary to avoid ambiguity with the syntax you chose, but it is a bit unfortunate. Consider (using the python syntax for clarity only):

a, b ?= b, a if swap else a, b

The restriction that does the work “to avoid abuse” is that of being a statement instead of an expression, not of having a single variable on the LHS.

Some other questions and observations.

Can you declare variables this way, using ?:=?

Other syntax in Go like ?= modifies the LHS (+=, <<=, etc.). That makes this a bit of an anomaly.

Right. I tried to avoid using expression vs statement because many folks get confused. So I wanted to use lay terms ie RHS LHS that anyone understands.

I see ?= just like I see :=. Within go, the spec makes clear that op= works when op is an arithmetic operator. ?= and := both work in this context, because neither ? nor : is an arithmetic operator, so there's no ambiguity/confusion. It becomes a singular multi-byte operator, just like || or << or >> or :=. And there's no ambiguity, and there's precedence in this specific limited case of "richer assignment" like := does.

Remember: there can only be one variable on the LHS. The syntax is really only applicable for:

(var)? varName ?= boolean_expr, trueValAssignableToType, falseValAssignableToType

Given that go already prevents if/switch expressions, the example you suggested is not possible in go in any syntax, and so doesn't apply.

[ugorji]

ifTrueVal if boolean_expr else ifFalseVal

Sorry, I didn't mean you were talking about including the ternary operator, I just was saying that writing:

var s ?= boolean_expr, ifTrueVal, ifFalseVal

Could be easier to read if you write:

var s ?= ifTrueVal if boolean_expr else ifFalseVal

If you see var s ?= boolean_expr, ifTrueVal, ifFalseVal is like writing a boolean_expr ? ifTrueVal : ifFalseVal

Key message in the proposal is that this is an operator that doesn't fit into an expression at all, because once it does, it can be misused.

See example of misuse:

var s ?= trueVal1 if boolean_expr_1 else trueVal2 if boolean_expr_2 else trueVal3 if boolean_expr_3 else falseVal 

Looking at above, I don't even know if the syntax is correct. The compiler might let me know. And this is why folks do not like the ternary operator when nesting is allowed.

By using commas, there cannot be any nesting. The operator is strictly attached to assignment to exactly one variable. It's like a function call that does:

func ternary(b bool, s1 string, s2 string) string {
  if b {
     return s1
  } else {
     return s2
  }
}

var s = ternary(boolean_expr, trueVal, falseVal)

This is the limited scope that this proposal allows.