Hi Sam. A couple small responses inline.

On Thu, Aug 16, 2018 at 8:13 AM Sam Vilain <s...@vilain.net> wrote:

> To me the biggest reason to want a ternary operator is to make it easier
> on the reader of the code.  If there's anything that go and python have in
> common, it's that both languages are designed to be easy to read (though
> with notable differences in emphasis about what makes it easy), and also
> relatively easy to tell whether code is correct.
>

I am not particularly familiar with the design process of Python. But
judging from the result, I find that very hard to believe, TBQH. I find
both of these things - reading Python and telling whether Python code is
correct - to be very hard things to do. ISTM that if two processes claim to
optimize for the same thing but achieve such different results, then either
they weren't optimizing for the same thing, or one of the two failed. I'm
uncomfortable claiming the latter, so I'd personally argue the former: That
it may be worth considering that we should use different words for what
Python aims for and what Go aims for (not that I have good suggestions).

With a ternary, it's very clear that after the statement, the assignment
> has occurred.
>
> result = test ? "a" : "b"
>
> With an `if' statement, you have to read a bit more:
>
> var result string
> if test {
>   result = "a"
> } else {
>   result = "b"
> }
>
> In most cases the analysis is very simple to tell that both code branches
> assign to `result'.  But there's a problem with this.  This is only easy to
> see if someone doesn't then come along and insert extra code into those
> nice welcoming code blocks:
>
> var result string
> if test {
>   result = "a"
>   // insert code here
>   funcCall()
> } else {
>   // insert other code here
>   funcCall2()
>   result = "b"
> }
>
> As a result, as the code is modified, the condition that 'result has a
> value' is not held and you end up with the zero value instead of something
> you expected.
>

I don't understand what you mean. Your code seems fine, what am I
overlooking?

On a larger point: I don't believe this to be a good argument. I'd argue
that if the logic of the latter is what you want, you will get there,
ternary expression or not. I'd argue that in practice, if you started with
a ternary expression, people would just remove that and write the code you
ended up with anyway. Because they want that logic and writing that
conditional statement is the way to achieve that logic.

But I'm not clairvoyant, so who knows what would happen in actual practice.


>
> Of course it's not as bad as in python or C because there is a separate
> `=' and `:=' operator, but as you can see above, this doesn't always come
> into play.  If you're assigning more than just an immediate constant, you
> probably don't want to start with `:=' and then re-assign based on the
> conditional.
>
> It also gets much more complicated to follow for cases where you might
> want to use a nested or chained ternary expression, or a more complicated
> value construction which has many ternaries within it.
>
> I've lost count of the times I've had to change:
>
> return FooBar{
>     Field: blah,
> }
>
> To:
>
> var foo FooBar
> if someCond {
>     foo.Field = blah
> } else {
>     foo.Field = bar
> }
> return foo
>
> In my experience code is clearer and easier to read if it does *not*
> contain re-assignments and branches, and temporary variables used only
> once.  With a ternary operator, you can code like that for cases where it
> makes sense.  I would much rather write:
>
> return FooBar{
>     Field: someCond ? blah : bar,
> }
>
> my 2¢,
> Sam
>
>
> On Wed, Aug 15, 2018 at 1:13 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> In my opinion Python serves as a poor argument here. I tend to use Python
>> as a example of a grab-bag language that adds any feature anyone considers
>> useful - without considering the cost. An Anti-Go, if you will :)
>> Gustavo Niemeyer actually wrote this up pretty well:
>> https://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward
>>
>> So, from my perspective, if you tell me "Python did not have ternary
>> operators, but after long and hard discussions, they caved", what I'm
>> hearing is "even *Python* didn't really need them". ;)
>>
>> (Disclaimer: This isn't meant as a dig at Python. I think Python is a
>> great language. But its design goals are very different from Go's)
>>
>> On Wed, Aug 15, 2018 at 8:33 AM Sam Vilain <s...@vilain.net> wrote:
>>
>>> I haven't seen all the discussion referenced, but I remember digging
>>> deep into the python language archives where Guido and others eventually
>>> relented and added ternaries (with the syntax "a if val else b"). I can't
>>> remember the argument which swung the consensus but the arguments against
>>> seem remarkably similar.
>>>
>>> Go does have a one-line ternary:
>>>
>>> var result = map[bool]string{false: "a", true: "b"}[test]
>>>
>>> It's less of a hack if you declare the lookup "table" separately.
>>>
>>> Sam
>>>
>>> On Aug 14, 2018 9:52 PM, Agniva De Sarker <agniva.quicksil...@gmail.com>
>>> wrote:
>>>
>>> Your answer is here -
>>> https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.
>>>
>>>
>>> On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann wrote:
>>>
>>> I’m new to Go and I imagine the idea of adding a ternary operator to Go
>>> has been discussed many times. Rather than repeat that, can someone point
>>> me to a discussion about why Go doesn’t add this? I’m struggling to
>>> understand why it is desirable to write code like this:
>>>
>>> var color
>>> if temperature > 100 {
>>>     color = “red”
>>> } else {
>>>     color = “blue”
>>> }
>>>
>>> Instead of this:
>>>
>>> var color = temperature > 100 ? “red” : “blue”
>>>
>>> Is the ternary really so confusing that it justifies writing 6 lines of
>>> code instead of 1? I realize I could eliminate two lines like the
>>> following, but this isn’t a good idea if the values come from function
>>> calls since there would sometimes be needless function calls.
>>>
>>> var color = “blue”
>>> if temperature > 100 {
>>>     color = “red”
>>> }
>>>
>>> ---
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to