Ternary operator needed in Go

[abiosoft]

I think there is need for ternary operator for neater codes.

if a > b {
c = a
else {
c = b
}

can easily be written as

c = a > b ? a : b

I think there should be consideration for this in future releases.

Or what do you guys think?

[Qtvali]

func iffI(c bool, a int, b int) int {
if c { return a } else { return b }
}

func iffS(c bool, a string, b string) string {
if c { return a } else { return b }

[John Asmuth]

One of the things that makes ternary operators interesting is lazy
evaluation. To make a function that would mimic this, it would need to
take functions as its parameters.

That being said I have the feeling it's unlikely to ever see this in
go. It certainly wasn't neglected due to forgetfulness.

For my personal style, I like not having a ternary operator. I feel
that making code too compact can make it unreadable (perl).

- John

[Qtvali]

On Dec 23, 8:44 pm, John Asmuth <jasm...@gmail.com> wrote:
> For my personal style, I like not having a ternary operator. I feel
> that making code too compact can make it unreadable (perl).
>
> - John

The opposite is also true - making it too long makes it unreadable.
Java, for example, makes your code longer - each line is very simple,
but there are a lot of them. I mean, getters and setters etc... it's
hard to find something from Java class, sometimes.

[eadfrith]

I think this was discussed quite a bit in the days after the initial
release of go.

If you want to get fancy you can always do something like this:

c := func(x, y int) int {if x>y {return x};return y}(a, b);

If Issue 65 (http://code.google.com/p/go/issues/detail?id=65) gets
resolved you could do

c := func(x, y int) int {if x>y {return x} else {return y}}(a, b);

Which looks a bit nicer.

I would say that if and when we get generics you could define
templated min/max functions, but then this would be hard to implement
without operator overloading. If you keep going down this route you
end up with C++ or D.

I think the Go way is to keep things simple - just use the code you
posted.

[Peter Froehlich]

On Wed, Dec 23, 2009 at 1:25 PM, Qtvali <qtv...@gmail.com> wrote:
> func iffI(c bool, a int, b int) int {
>  if c { return a } else { return b }
> }

map[bool]int{true: a, false: b}[a > b]
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Herman]

On Dec 23, 10:59 am, Peter Froehlich <peter.hans.froehl...@gmail.com>
wrote:

> map[bool]int{true: a, false: b}[a > b]

This is beautiful abuse. Simultaneously I feel respect and disgust.

Humans can figure the intent here. Can an optimizing compiler?
Probably not this one yet.

[Ed Marshall]

On Wed, Dec 23, 2009 at 12:59 PM, Peter Froehlich <peter.hans...@gmail.com> wrote:

On Wed, Dec 23, 2009 at 1:25 PM, Qtvali <qtv...@gmail.com> wrote:
> func iffI(c bool, a int, b int) int {
>  if c { return a } else { return b }
> }

map[bool]int{true: a, false: b}[a > b]

And thus begins the Obfuscated Go Code Contest. That is awesomely disgusting. ;-)

Both solutions suffer from the same problem that a tern() function I proposed a few weeks ago on the list had, although it's not immediately obvious from the suggested use case: both arguments are evaluated regardless of whether or not the condition fails or succeeds, while a true ternary operation would only evaluate the necessary result, much like a plain if/else would.

I admit to liking the syntax of something like "val := expr1 if cond else expr2", but writing out an if/else certainly hasn't been painful.

--
Ed Marshall <e...@logic.net>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/

[Qtvali]

On Dec 23, 9:17 pm, Herman <herman.sch...@gmail.com> wrote:
> On Dec 23, 10:59 am, Peter Froehlich <peter.hans.froehl...@gmail.com>

> Humans can figure the intent here. Can an optimizing compiler?
> Probably not this one yet.

Once again: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html

Intent might be to call both and return one. That's why "||" now
leaves second one uncalculated if first one is false, by default -
without excplicitly stating this, code would be broken. Too much magic
breaks things.

[Steven Blenkinsop]

Ooh ooh ooh!

map[bool]int{true: func()(int){return a}, false: func()(int){return b}}
[a > b]()

Horrendous :)

you might as well just do

x := func()(int){ if a > b { return a }; return b }()

since funcs are full closures.

[Jason Catena]

How about interfaces? Seems you could have a Max function that takes a
Comparable interface type, and uses the appropriate GreaterThan method
of the underlying type. The Max function would be polymorphic, which
seems an advantage of the ternary operator and lacking in these idioms.

[Marcin 'Qrczak' Kowalczyk]

2009/12/25 Jason Catena <jason....@gmail.com>:

Go is not ready for such a Max yet. Returning just Comparable when
both arguments are ints loses static type information and a cast
(implying an unnecessary runtime check) would be needed to recover it;
it should better have the same result type as the type of arguments.
Also, plain ints won't support Comparable.

And this doesn't cover other uses of if-expression.

--
Marcin Kowalczyk

[Jason Catena]

From the results so far on this thread, I'd be inclined to ignore Max
as a separate function, and always inline it. That's alright I guess
for a small common idiom like Max, but I wouldn't want to inline every
function because the polymorphism is clumsy.

[matti....@qvik.fi]

In addition (or instead of) the ternary operator; I would very much like to see an operator like:

Python's OR for selecting a non-None value:

foo = bar or baz

Swift's ?? operator for using a value if non-nil or otherwise another value:

foo = bar ?? "default"

[Ian Lance Taylor]

Go doesn't have a general None or nil value, so this seems
underspecified. It also doesn't seem to fit well with the language,
which is careful to avoid constructs like implicit conversion to bool.

Ian

[Christopher]

Python resisted this for a while, depending on it's OR behavior. However, the OR behavior has 

a lot of critics and criticisms.  See https://www.python.org/dev/peps/pep-0308/

The if expression is really nice, and quite clear. I use it a lot. It doesn't require null types or

other exotic features.

[Dave Cheney]

Prior to this recent post, this thread had been dormant for eight years. I think the results speak for themselves and this topic does not need to be revisited again.

[john howitt]

No! no! please no! -- runs screaming from the room

[Nicolas Grilly]

On Monday, October 16, 2017 at 8:37:25 PM UTC+2, Dave Cheney wrote:

Prior to this recent post, this thread had been dormant for eight years. I think the results speak for themselves and this topic does not need to be revisited again.

At least, it proves people are searching in the mailing list archive before posting, which is great, isn't it? ;-)

[Jesper Louis Andersen]

If a language has two syntactic classes, statements and expressions, then having a choice operator in both seems somewhat redundant and bounds for confusion. If on the other hand, your language only has expressions, then there is only a single choice operator, and this whole thing doesn't matter.

Go, to me, cares about explicit and somewhat verbose notation. It cares about being small, coherent and readable more than it cares about compressing programs down to succinctness. In that vein, it often shies from syntactic sugar constructions. And I think it is worthwhile to have a language going that route. Smaller languages are way easier to learn. Language size is often a liability rather than a benefit. Other languages can try different routes.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.