Hacker News Reader

Comment by maccard | Hacker News Reader

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)

View on HN

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

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.

   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