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

Comment From: gabyhelp

Similar Issues

  • https://github.com/golang/go/issues/60502
  • https://github.com/golang/go/issues/31659
  • https://github.com/golang/go/issues/36288
  • https://github.com/golang/go/issues/23248
  • https://github.com/golang/go/issues/33171

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

Comment From: 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.