Hacker News Reader

Comment by boring_twenties | Hacker News Reader

Is there a ternary operator yet?

I don't write Go code but I admire them for sticking to their guns to not include it. Having had to decipher nested ternaries in the past, it's not something I want to have to think about again.

Python has some interesting shortcuts too, like being able to do `if 1 <= number <= 10:` to do chained comparisons but I much prefer the longer hand syntax. I have a solid amount of Python experience but no formal math background beyond HS Algebra. I often don't see this shorthand method to compare a range but when I do I always have to stop and decipher it.

I know this thread isn't about Python but I think it falls in line with this conversation. A language that sticks to slightly more verbose syntax for the sake of crystal clear clarity is very appealing.

just because someone can abuse a language feature doesn't mean you should bar every responsible programmer from using it.

Yeah, but there are other languages that support the idea of there being many different ways to do something and also give you a lot of rope to either hang yourself or create "clever" solutions (this isn't a bad thing btw, besides Python I also really like Ruby too).

I think we should respect language creators to keep a clear vision on their language, this way the audience who uses it can either strongly love it or hate it. If you try to do everything and cater to everyone then you'll end up with a worse result IMO.

It's the same way with music. You wouldn't expect a deathcore band to release a country album because a small portion of folks were interested in that, it would alienate their true fans and would likely leave the band internally not liking that decision. If you want to listen to a different style of music then you can pick a different band or genre.

No and there likely never will be:

https://go.dev/doc/faq#Does_Go_have_a_ternary_form

That's what they said about generics, and yet here we are.

edit: Wrong, see below

That's not true at all. Go core team always thought of adding generics in Go but Go core team couldn't reach a consensus on any proposed implementation and design for generics into Go, until this design.

https://go.dev/blog/why-generics

OK, I stand corrected.

It's unfortunately misguided in my opinion. With a ternary operator you can initialize in one line, e.g.

    x := val ? foo() : bar()

Versus

    var x Type // now this is default initialized, which may or may not be a valid state for your program
    if val {
        x = foo()
    } else {
        x = bar()
    }

Honestly, I'd be fine with it being for initialization only (like the walrus operator)

How about f(a ? b : c, d, e)?

The go alternatives are too horrible to even contemplate, but here goes:

  if a {
     f(b, d, e)
  } else {
     f(c, d, e)
  }

  var tmp WhatFuckingTypeIsThisAgain
  if a {
     tmp = b
  } else {
     tmp = c
  }
  f(tmp, d, e)

It's hard to say which one is worse, but there is no doubt that the C version is "unquestionably easier to read."

my gut reaction was "no, that's exactly why they don't want these sorts of constructs" but the alternative (only allowing it in init statements) is worse I think. Only allowing in init statements is how you end up with the c++ initialization mess.

Re; your example, what about

    tmp := a ? b : c
    f(tmp, d, e)

Even in C++ that's likely how I'd write it.

Works for me.

Or make if… an expression instead of a statement.

Go core are very smart people so I’m sure they have their reasons, but my Lisp-addled brain can’t understand why you’d ever want statements instead of expressions with potentially discarded values.

Works great in Rust, but almost everything is an expression there.

I sadly don’t see it getting added to Go.

Ruby as well

I agree with this. The limited location I find that I really miss ternary operations is initialization.

  v := if foo() {
    7
  } else {
    11
  }

But this means {} blocks now have values, which is weird in a C derivative. Of course, one could do

  v := func() int {
    if foo() {
      return 7
    } else {
      return 11
    }
  }()

but... that's kind of awful.

As best I can tell from the history books, the creator of Go, Ken Thompson, was responsible for inventing the ?: syntax (although the ternary concept is older). As such, there is probably nobody more familiar with what you propose than the Go team, so there may be some wisdom in the choice to actively not include it in Go.

Unfortunately the only info we have to go on is the link above [0], which isn't a good argument IMO. If there's other resources that say differently I'd love to hear them!

[0] https://go.dev/doc/faq#Does_Go_have_a_ternary_form

   x = bar()
   if val {
       x = foo()
   }

Is both shorter and functionally more equivalent with the ternary example.

I did think of this, but left it out of the original post to keep it shorter. It is functionally better, but in terms of reading code, I find it easier to keep initialization blocks together and linearly scoped; the optional branch means I have to actually figure out which branch is being taken. That's definitely in the personal preference area though

I'd still rather a ternary over any of the above options though!

But you execute bar() when you don't need it. At best it's wasteful, at worst bar() actually is sendNuke().

Nope, that's incorrect. When val is true both functions are called.

I like to do it this way

  x := func() Type {
      if val {
          return foo()
      }
      return bar()
  }()

I've used that one in C++ quite a lot for const initializing variables that have awkward initialization steps, and it's probably my favourite of the options, but it's still nasty; having to declare the return type of the function removes one of my favourite things about golang!

This is supposed to be ... easier to read than `x := val ? foo() : bar()`? Really?

Reply on news.ycombinator.com