Hi,
On Wed, Aug 15, 2018 at 1:23 PM Mark Volkmann <r.mark.volkm...@gmail.com>
wrote:
> I understand that many requests for syntax additions are rejected on two
> grounds.
Really though, the reaction always happens on the same grounds: It is not
shown that the benefit outweighs the cost. You mention the cost in your
message and try to reduce that (which is fair). But even if I agree that
the cost is relatively minor, I still also disagree about the benefit. It
seems very small too.
> The first is ternaries. What if only simple, non-nested ternaries were
> supported? For example, color := temperature > 100 ? “red” : “blue”.
>
Personally, I'm worried about the implications this has on the second cost
you mentioned: Size of the spec. It's actually pretty simple to specify the
grammar in a way to support general ternary conditional expressions. It's
harder to do that with this limitation.
> This seems so much more clear than the map[bool]:string trick that some
> have proposed.
>
To be clear: That is not the alternative you should be using. You should be
using if-statements. And I disagree that a ternary conditional expression
is significantly (if at all) clearer than a conditional statement.
Writing this with an if statement takes either 4 or 6 lines.
>
LOC is not a useful primary measure of clarity or readability. For example,
list-comprehensions could definitely reduce the LOC in Go code, but I'd
argue that they reduce readability.
This comes up often enough in code to make a significant difference. I
> think it’s hard to argue that this has the potential to make code harder to
> read if they can’t be nested.
>
I think this is an inversion of the argument. The default decision for
language changes is "reject", so the onus is on the proponents of a feature
to argue that it significantly *improves* on the design goals of Go - most
significantly, to enable large-scale software engineering.
One way to do that, would be to try and make an argument that it makes code
easier to read. Personally, I think that's a hard argument to make, given
how subjective something like "readability" is and that the designers of
the language have already explicitly said that they don't think it does.
> The second is arrow functions. What if only functions that return the
> result of a single expression were supported? For example, n => n * 2.
> Compare this to func (n int) { return n * 2 }. The value of this is closely
> tied to whether generics are added to the language at some point.
>
> Adding just a few things like these to the language might help with
> adoption and that in itself is a worthwhile goal. I suspect many developers
> that love Go aren’t currently using it on real projects. Getting more
> developers to consider Go makes that more likely.
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
>
> On Aug 14, 2018, at 12:18 PM, Axel Wagner <axel.wagner...@googlemail.com>
> wrote:
>
> There is lots of discussion findable here:
> https://groups.google.com/forum/#!searchin/golang-nuts/ternary%7Csort:date
> There's a bit of discussion on the issue tracker:
> https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ternary+operator --
> in particular https://github.com/golang/go/issues/23248
> There's more discussion on the reddit:
>
> https://www.reddit.com/r/golang/comments/5dqpab/what_is_the_reasoning_behind_go_not_having_a/
>
>
> On Tue, Aug 14, 2018 at 6:43 PM Mark Volkmann <r.mark.volkm...@gmail.com>
> 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.
