5 ms·

No and there likely never will be: https://go.dev/doc/faq#Does_Go_have_a_ternary_form https://go.dev/doc/faq#Does_Go_have_a_ternary_form

boring_twenties 5y ago
That's what they said about generics, and yet here we are. edit: Wrong, see below
- knodi 5y ago
  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 https://go.dev/blog/why-generics
  - boring_twenties 5y ago
    OK, I stand corrected.
  - deleted 5y ago
    [deleted]
maccard 5y ago
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)
- randomdata 5y ago
  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.
  - maccard 5y ago
    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 https://go.dev/doc/faq#Does_Go_have_a_ternary_form
- boring_twenties 5y ago
  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) } or 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."
  - maccard 5y ago
    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.
    - boring_twenties 5y ago
      Works for me.
- User23 5y ago
  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.
  - dontlaugh 5y ago
    Works great in Rust, but almost everything is an expression there. I sadly don’t see it getting added to Go.
    - lamontcg 5y ago
      Ruby as well
  - ts4z 5y ago
    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.
- jeddy3 5y ago
  x = bar() if val { x = foo() } Is both shorter and functionally more equivalent with the ternary example.
  - maccard 5y ago
    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!
  - Leherenn 5y ago
    But you execute bar() when you don't need it. At best it's wasteful, at worst bar() actually is sendNuke().
  - boring_twenties 5y ago
    Nope, that's incorrect. When val is true both functions are called.
- thegeekpirate 5y ago
  I like to do it this way x := func() Type { if val { return foo() } return bar() }()
  - maccard 5y ago
    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!
  - boring_twenties 5y ago
    This is supposed to be ... easier to read than `x := val ? foo() : bar()`? Really?
  - deleted 5y ago
    [deleted]

boring_twenties 5y ago

That's what they said about generics, and yet here we are. edit: Wrong, see below

knodi 5y ago
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 https://go.dev/blog/why-generics
- boring_twenties 5y ago
  OK, I stand corrected.
- deleted 5y ago
  [deleted]

maccard 5y ago

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)

randomdata 5y ago
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.
- maccard 5y ago
  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 https://go.dev/doc/faq#Does_Go_have_a_ternary_form
boring_twenties 5y ago
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) } or 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."
- maccard 5y ago
  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.
  - boring_twenties 5y ago
    Works for me.
User23 5y ago
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.
- dontlaugh 5y ago
  Works great in Rust, but almost everything is an expression there. I sadly don’t see it getting added to Go.
  - lamontcg 5y ago
    Ruby as well
- ts4z 5y ago
  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.
jeddy3 5y ago
x = bar() if val { x = foo() } Is both shorter and functionally more equivalent with the ternary example.
- maccard 5y ago
  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!
- Leherenn 5y ago
  But you execute bar() when you don't need it. At best it's wasteful, at worst bar() actually is sendNuke().
- boring_twenties 5y ago
  Nope, that's incorrect. When val is true both functions are called.
thegeekpirate 5y ago
I like to do it this way x := func() Type { if val { return foo() } return bar() }()
- maccard 5y ago
  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!
- boring_twenties 5y ago
  This is supposed to be ... easier to read than `x := val ? foo() : bar()`? Really?
- deleted 5y ago
  [deleted]