spec: <Feature> Ternary operators

[sinnlosername]

Currently, go doesn't support ternary operators. As far as I know, the main argument against it is "People will misuse it, so it will be harder to read code". I don't think this will happen, here's why:

Most developers write their code with the default code conventions. Sometimes they change small things like the tab size or a newline before a {, but overall, it's the same. So who is misusing them? New developers do so. People who started developing are doing many crazy things in their code, but their is one thing most new developers don't do, especially if it's their first language: They don't contribute much to the community, until they are good enough. And if they are, they'll know code conventions.

Take a look at java. How often have you seen java code which is unreadable, because people use ternary operators? I'm developing java since years and I never had this problem when reading code on github, stackoverflow or somewhere else.

I think, ternary operators would make code smaller, while it's still good to read. Here are some examples how they could look like and why they are useful.

Example one

Without:

var test string
testMap, err := getMap()

if err != nil {
    test = testMap["test"]
} else {
    test = "..."
}

With them (parenthesis are optional, but this looks better with them):

testMap, err := getMap()
test := (err == nil ? testMap["test"] : "...")

They could also be made without a "else". Such a feature was also requested here. Example:

testMap, err := getMap()
test := (err == nil ? testMap["test"])

Example two

Without:

func abs(a int) int {
if a >= 0 {
    return a
}

return -a
}

With:

func abs(a int) int {
    return a >= 0 ? a : -a
}```

Tell me what you think about it in the answers. 👍 

[adamdecaf]

This was rejected previously #20774

[sinnlosername]

@adamdecaf Half of my request is about this argument, so why not trying it again?^^

[dominikh]

The argument has been had many times over.

• "Code will be shorter" is not a convincing argument – we do not care about turning 4 lines into 1. The current way reads just fine.

• Part of Go's design is to be easy to learn for newcomers, so "only newcomers abuse ternary operators" is not an argument in your favour, even if it were true – which it isn't. The cleverer someone thinks they are, the more complex their use of ternary operators will be. This is very evident in the C and C++ communities.

I am going to close this issue as the decision has been made a long time ago and no new arguments have been presented.

[sinnlosername]

@dominikh
"Code will be shorter" was maybe the wrong way to call it. I think in all examples I made "Code will be less complex" would match better.

So, why did this happen in the C(++), but not in the Java community? Anyway, Most ternary abuse could be prevented by limiting them to one line.

Also, I think it's a very bad argument to forbid something, because it could be misused. Or would you ssay: "Let's forbid knifes, because they can be misused"? You shouldn't think about those few people who are missing using it, think about people who'll use it correctly to make code better.

[dlsniper]

Duplicate of #20774 (for github tracking).

Maybe it's worth having an entry in the https://golang.org/doc/faq as to why this is not supported. Even if I agree that sometimes a single line ternary, with a single ternary in it, I choose consistency over it.

[sinnlosername]

I think go developers should really care more about the "developing" part, instead of the "reading others code" part. :/

[PaulReiber]

@sinnlosername we really "should" refrain from using the word "should" here. This is not a forum for telling people how to think or work.

Ternary operators are syntactic sugar that obfuscates code. They are not needed. It's that simple.

[bradfitz]

I think go developers should really care more about the "developing" part, instead of the "reading others code" part. :/

@sinnlosername, when "programming in the large" (large code bases with large teams over long periods of time), code is read WAY more often than it's written, so we optimize for readability, not writability.