proposal: simplified ternary operators

[jucardi]

Proposal Details

Problem

I'm sure you get this a lot. I always wondered why ternary operators were not built into the language and found this https://golangdocs.com/ternary-operator-in-golang

I personally don't think that this

var result string
if ok {
    result = "success"
} else {
    result = "failure"
}

is easier to read than this

results := ok ? "success" : "failure"

Which makes me disagree that "makes the code easier to read" (in most cases)

Why?

• 7 to 1 ratio in lines of code
• Additional unnecessary nesting, so I have to disagree that makes the code easier to read.

When do ternary operators make statements harder to read?

• If true/false values come from another function

E.g:

value := condition ? SomeFunctionWithALotOfVariables(someVariable1, someVariable2, someVariable3) : SomeOtherFunction()

• Nested ternary operators

E.g:

value := condition ? valueIfTrue : ( anotherCondition ? value2 : value3 )

• Convoluted condition

E.g:

value := (condition1 || condition) && !conditionFromFunction(someVar) ? valueIfTrue : valueIfFalse

But for simple values that come from either a constant or a variable already declared, the simplicity is undeniable.

Proposal

Allow ternary operators where the condition and true/false assignments have to come from variables or constants, never from functions or other nested ternary operators.

Example of some allowed expressions:

value := condition ? 1 : 0

const predefinedString = "someValue"

value := condition ? predefinedString : "hardCodedInLineString"

Example of complex expressions that could be simplified if needed:

Case for complex condition:

Instead of

value := (condition1 || condition2) && !conditionFromFunction(someVar) ? valueIfTrue : valueIfFalse

Declare the condition in a boolean variable first

condition := (condition1 || condition2) && !conditionFromFunction(someVar)

value := condition ? valueIfTrue : valueIfFalse

Case for complex values provider:

Instead of

value := condition ? SomeFunctionWithALotOfVariables(someVariable1, someVariable2, someVariable3) : SomeOtherFunction()

Use a value provider function

var provider func() string

provider := condition ? providerIfTrue : providerIfFalse
value := provider()

Conclusion

Ternary operators can sometimes become complex, but this proposal prevents that from happening, the best of both worlds

The use of ternary operators should be a choice of the developer, people that don't like to use that can always go back to using if-else statements, I don't believe the reasoning behind the article is a good enough reason to take away the choice from developers. My 2 cents

[gabyhelp]

Similar Issues

• proposal: all : ternary operators in golang  #60502
• proposal: Go 2: spec: conditional-assign (?=) for limited ternary operator functionality #31659
• x/website: reword FAQ answer on lack of ternary operator #36288
• spec: <Feature> Ternary operators #23248
• proposal: Go 2: add a ternary conditional operator #33171

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

Closing as a dup of several previous issues, as noted by gabyhelp.

Note that we don't use the issue tracker for discussion. To discuss this, please use a forum. See https://go.dev/wiki/Questions. Thanks.