Go if else syntax .. suggested replacement

[lgo...@gmail.com]

It sure would be nice if Go syntax allowed programmers to replace 

if ( test) {

...do sonething

} else {

..do something else

}

with 

? (test) {

//...do something

}

{

//..do something else

}

The ? operator can be anything the Go language team considers appropriate

[andrey mirtchovski]

> ? (test) {
> //...do something
> }
> {
> //..do something else
> }

I believe the Go team considered this very carefully early on the
language's development and came to the decision to use "if test" for
"? (test)" and "} else {" for "}{" (without the implied newline). They
also threw in "} else if test {" for good measure, which your example
does not cover.

[Robert Engels]

Why? You have saved 5 characters for no practical gain. I think you would enjoy Ada. 

--
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.

[wilk]

On 24-04-2019, lgo...@gmail.com wrote:
> ------=_Part_538_706677508.1556067911841
> Content-Type: multipart/alternative;
> boundary="----=_Part_539_1965717614.1556067911841"
>
> ------=_Part_539_1965717614.1556067911841
> Content-Type: text/plain; charset="UTF-8"

>
> It sure would be nice if Go syntax allowed programmers to replace

I suggest you to use switch case...

--

[Jan Mercl]

On Wed, Apr 24, 2019 at 3:05 AM <lgo...@gmail.com> wrote:
>
> It sure would be nice if Go syntax allowed programmers to replace
>
> if ( test) {
> ...do sonething
> }

That's not how Go's if statement looks. Gofmt will remove the
superficial parentheses around 'test'.

Wrt the rest of the proposal, today, this is valid code:

if test {
foo()
}
{
bar()
}

How would one write the it under the proposal?

[Robert Engels]

Though to the ops point, not sure why Go doesn’t have the ternary operator - which is pretty ubiquitous. 

[Mark Volkmann]

> On Apr 24, 2019, at 6:22 AM, Robert Engels <ren...@ix.netcom.com> wrote:
>
> Though to the ops point, not sure why Go doesn’t have the ternary operator - which is pretty ubiquitous.

The idea of adding the ternary operator to Go has been debated many times. It’s clear that those in charge have a strong dislike for it. For me the lack of the ternary operator is one of main things I dislike about Go. It’s nails on a chalkboard for me to write a five line “if” statement when it could have been a one line assignment statement.

[Jan Mercl]

On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann <r.mark....@gmail.com> wrote:

> The idea of adding the ternary operator to Go has been debated many times. It’s clear that those in charge have a strong dislike for it. For me the lack of the ternary operator is one of main things I dislike about Go. It’s nails on a chalkboard for me to write a five line “if” statement when it could have been a one line assignment statement.

That's a nice example why Go does not have the ternary operator.
Fitting five if statements into one line makes the code probably
unreadable just for the imaginary gain of saving some vertical screen
space.

[Robert Engels]

That’s not what he meant. It takes 5 lines for a trivial assignment if/else rather than 1 line with a ternary with no loss in readability.

[L Godioleskky]

The lack of a Go ternary operator is at odds with Go's major theme of clean and easy to read syntax. Those who choose not to use the ternary operator can always resort back to Go's current 'if -else' or 'case' syntax. So Go syntax suffers no negative impact by adding the ternary op to its syntax list.  Those opposed to the ternary op should not be allowed to deny it use other Go programmers, that consider it useful.

[Jan Mercl]

On Wed, Apr 24, 2019 at 3:48 PM L Godioleskky <lgo...@gmail.com> wrote:
>
> The lack of a Go ternary operator is at odds with Go's major theme of clean and easy to read syntax. Those who choose not to use the ternary operator can always resort back to Go's current 'if -else' or 'case' syntax. So Go syntax suffers no negative impact by adding the ternary op to its syntax list. Those opposed to the ternary op should not be allowed to deny it use other Go programmers, that consider it useful.

That's backwards. Those who has to read the code can no more chose not
to decrypt the unreadable 4-level nested ternary operations instead of
5 if statements.

And to follow on your "logic". If you add to Go even just 10% of what
people consider useful, it will become a new C++, only much worse. And
again by your very logic. Why we, that haven't chosen to code in C++
in the first place, would be denied by others to use Go, when those
others have C++ already at hand?

Let everyone use the language he/she likes. Why ruin it for others
instead of that by forcing Go to become the same as his/her other
favorite language?

[Mark Volkmann]

Are there really developers that find this unreadable?

color := temperature > 80 ? “red” : “green”

I know what you are going to say. People will nest them. But even nested usage can be readable when formatted nicely with one condition per line. Another alternative is to allow only unnested ternaries.

R. Mark Volkmann
Object Computing, Inc.

[Ian Lance Taylor]

The lack of the ?: operator in Go is a FAQ:
https://golang.org/doc/faq#Does_Go_have_a_ternary_form .

Ian

[Robert Engels]

Yes, but the FAQ has similar concerns about readability and maintainability as reasons for not having generics, but adds the language “may change”... not sure that is consistent with the views on the tenant operator.

[Marcus Low]

I personally do not find ternary operators to be readable in any form.

For those who are truly desperate for that cosmetic one-line kick, though, here's an example you can use (which looks just about as unreadable as any ternary operator out there):

// ternary returns 12345 if x is positive (x > 0).
// It returns -1 otherwise.
func ternary(x int) int {
    return map[bool]int{true:12345,false:-1}[x>0]
}

[Marcus Low]

color := map[bool]string{true:"red",false:"green"}[temperature>80]

Here you go.

[Robert Engels]

I’m pretty sure you’re joking... but I think most are referring to simple usages, like this (from my own code). Clearly, there are others was of designing it to avoid the usage, but sometimes what is simple really is simpler. 

var datalen int32

if value == nil {

   datalen = removedKeyken 

} else {

   datalen = len(value)

[Marcus Low]

Yeah of course I was joking... the solution I provided does work for the "I need a one-liner" mentality, though. 

I believe this following solution fits your use case, and is simpler to read too:

datalen := removedKeyken // removedKeyken must have been int32 in your example.

if value != nil {

   datalen = len(value)

}

[Mark Volkmann]

I'm at a loss as to how that could be considered more readable that a single ternary.

You've successfully changed five lines to four lines, but that's still a long way from one line.

--

[Robert Engels]

I agree, and I think the ternary represents the logic much cleaner than if/else in this case. This would be especially true if you could do:

final datalen := value==nil ? removedKeyken : len(value)

[andrey mirtchovski]

Here's the lore associated with the subject: Ken wanted ternary, Rob
and Robert did not. They overruled Ken (remember, early on all three
had to agree for a feature to go in). The end.

The number of frivolous and egregious abuse of ternary that I've seen
in _modern_ C code is too high.jpg

[Kurtis Rader]

+100 to that sentiment. While the brevity of a ternary expression is  useful for trivial cases it tends to be abused. For your amusement/horror here are just a few, of a couple hundred, examples of ternary being abused in the AT&T AST (which includes ksh) source:

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/cmd/ksh93/edit/hexpand.c#L447

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/cmd/ksh93/sh/string.c#L344-L346

https://github.com/att/ast/blob/8504cd407846d192881a94d507333697f016a85a/src/lib/libast/include/sfio.h#L359-L360

https://github.com/att/ast/blob/8504cd407846d192881a94d507333697f016a85a/src/lib/libast/include/cdt.h#L313-L316

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/lib/libz/deflate.c#L597-L609

For those who don't want to follow those links this is the code from the first URL above:

lc_unicodeliterals = quote=='u' ? 1 : quote=='U' ? 0 : !!(ast.locale.set & AST_LC_unicodeliterals);

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Ian Lance Taylor]

On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski
<mirtc...@gmail.com> wrote:
>

> Here's the lore associated with the subject: Ken wanted ternary, Rob
> and Robert did not. They overruled Ken (remember, early on all three
> had to agree for a feature to go in). The end.

I may easily misremember, but that doesn't match my recollection. I
don't remember what position Rob and Robert took, but as I recall Ken
was generally opposed to the ternary operator. He had been in part
responsible for adding it to C, and felt that it had been a mistake.

Ian

[David Riley]

I enthusiastically concur with this. I understand the antagonism toward the ternary statement to a point, but there are some things that it just makes about a million times easier without sacrificing readability:



fmt.Printf("This parrot is %s.\n", is_dead ? "pining for the fjords" : "alive")



This isn't just a toy example. Nothing (to my mind) is unclear about this statement.

I run into this sort of thing every day; the main thing the ternary statement relieves me of is either writing convoluted if/switch/map statements when a single line would do, or repeating myself. I'd have to do one or the other to resolve the above one-liner, and it wouldn't enhance readability in the slightest.


- Dave

[David Riley]

On Apr 24, 2019, at 12:34 PM, Marcus Low <marc...@gmail.com> wrote:
>
> On Wednesday, April 24, 2019 at 10:08:53 PM UTC+8, Mark Volkmann wrote:
>> Are there really developers that find this unreadable?
>>
>> color := temperature > 80 ? “red” : “green”
>>
>> I know what you are going to say. People will nest them. But even nested usage can be readable when formatted nicely with one condition per line. Another alternative is to allow only unnested ternaries.
>>

> color := map[bool]string{true:"red",false:"green"}[temperature>80]
> Here you go.

Pardon my bluntness, but it is silly to assert that this is anywhere near the readability of the ternary statement. The entire point of the ternary statement is that it is concise and spartan; this is cluttered and overwrought.

Yes, people can (and will) abuse it. That doesn't seem to have stopped us from having a reflection library, which is arguably much worse for readability and more pernicious compared to ternary statement abuse.

There are very few cases where you can force good coding hygiene by removing language features. This isn't one of them. If you wanted to force good coding style, put a check for nested ternaries in go vet along with other readability issues.


- Dave

[Chris Broadfoot]

On Wed, Apr 24, 2019 at 4:22 AM Robert Engels <ren...@ix.netcom.com> wrote:

Though to the ops point, not sure why Go doesn’t have the ternary operator - which is pretty ubiquitous. 

https://golang.org/doc/faq#Does_Go_have_a_ternary_form

[Andrew Klager]

Is this so bad?

func ternary(cond bool, pos, neg interface{}) interface{} {

if cond {

return pos

} else {

        return neg

}

}

color := ternary( temp < 80, "blue", "red")

[andrey mirtchovski]

> I may easily misremember, but that doesn't match my recollection. I
> don't remember what position Rob and Robert took, but as I recall Ken
> was generally opposed to the ternary operator. He had been in part
> responsible for adding it to C, and felt that it had been a mistake.
>
> Ian

I am happy to stand corrected. I believe it was an offhand comment by
either Rob or Russ in one of the early Go talks. Unfortunately hard to
find 10 years later, especially in non-transcribed videos.

[lgo...@gmail.com]

If instead of writing:  temperature > 80 ? red : green

you choose to follow Marcus and write instead:    map[bool]string{true:"red",false:"green"}[temperature>80]

OR call 

func ternary(x int) int {

    return map[bool]int{true:12345,false:-1}[x>0]

}

Go right ahead ! ..as they say,  "different strokes for different folks" 

But don't deny others the ability to choose the first alternative

[lgo...@gmail.com]

For me, choosing to write    

color = temp < 80 ? { "blue", "red") 

 vs 

func ternary(cond bool, pos, neg interface{}) interface{} {

if cond {

return pos

} else {

        return neg

}

}

color := ternary( temp < 80, "blue", "red")

is a no brainer

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@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 golan...@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 golan...@googlegroups.com.

[Mark Volkmann]

Nested ternaries are fairly readable in JavaScript these days due to the use of Prettier for code formatting.

gofmt could do the same.

For example, this:

lc_unicodeliterals = quote=='u' ? 1 : quote=='U' ? 0 : !!(ast.locale.set & AST_LC_unicodeliterals);

could be formatted to this:

lc_unicodeliterals =

  quote == 'u' ? 1 :

  quote == 'U' ? 0 :

  !!(ast.locale.set & AST_LC_unicodeliterals);

[lgo...@gmail.com]

Just to clarify :  My original proposal was to include as part  of Go the syntax

(test) ? {

{ //..code block for test=true

} : {

  //..code block for test=false

} 

I am NOT in favor of allowing nested ternary operations

In addition, I also propose allowing un-nested '?' as an alternative assignment statement i.e.  var = (temp >80) ? "red": "blue"

Thus, any further discussion of this topic should not involve issues related to nested ternary operations 

[Dan Kortschak]

How would you preclude it?

[Michael Jones]

switch test {

case true: 

  //..code block for test=true

case false:

  //..code block for test=false

} 

--
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.

--

Michael T. Jones
michae...@gmail.com

[Dan Kortschak]

I don't think that's an answer to my comment. Was it intended to be?

lgodio wrote that they wanted ternary operators, but were not
advocating that it be possible to allow nested ternary operations. I
don't see how this is possible if you write the grammar as the only
sensible interpretation

TernExpr = Expression "?" Expression ":" Expression .

Given that TernExpr would be an Expression.

The only way out of the natural possibility of having nested ternary
operator expressions would be a special case

TernExpr = NonTernExpr "?" NonTernExpr ":" NonTernExpr .

Which would then need documentation to explain it, and numerous posts here complaining about this weird edge case and how they should be allowed to write code however they want.

> *Michael T. Jonesmich...@gmail.com <michae...@gmail.com>*
>

[Robert Engels]

Your original proposal did not have the colon and also implied the {} were mandatory. And what stops the sane syntax from. Ring nested ?

--

[Robert Engels]

Wow that was some bad typing + bad auto correct...

[David Riley]

Well, Ken is giving the keynote at the Vintage Computer Festival East this year, maybe I can ask him then. :-)


- Dave

[andrey mirtchovski]

Please do! We need to resolve this connundrum for the next 5
generations of computer programmers!

[David Koblas]

IMHO I've wanted a switch expression, rather than a switch statement for a while.

value := switch test {
  case true => "red"
  case false => "blue"
}

or

value := switch item.(type) {
  case int => item
  case string => strconv.Atoi(item)
  case time.Time => {
    ... something more involved ... returning an int
  }
}

Sure, not as compact as ternary -- but far more powerful and useful.

[Matt Harden]

On Wed, Apr 24, 2019 at 8:42 PM David Koblas <da...@koblas.com> wrote:

IMHO I've wanted a switch expression, rather than a switch statement for a while.

I've wanted that too, but what we already have really isn't that bad.

value := switch test {
  case true => "red"
  case false => "blue"
}

value := "blue"

if test {

  value = "red"

}

value := switch item.(type) {
  case int => item
  case string => strconv.Atoi(item)
  case time.Time => {
    ... something more involved ... returning an int
  }
}

Note that the above won't work; you must have a default case as well, for almost any switch expression.

value := 0

switch v := item.(type) {

  case int:

    value = v

  case string:

    value = strconv.Atoi(v)

  case time.Time:

    ...

[Reto]

On Wed, Apr 24, 2019 at 04:24:41PM -0500, Andrew Klager wrote:
> Is this so bad?

Yes, it's horrible as you'll loose any type information you had.
Meaning the next thing you naturally had to do was type cast it, which isn't the nicest syntax to begin with.
By then it's probably more work than just using if / else

[Lucio]

But don't deny others the ability to choose the first alternative

 

That's not what's being denied: what is being denied, is the ability to write nested ternaries I then have to debug. Fat lot of good it will do me, that  vet reports it to be a misuse.

Lucio. 

[Robert Engels]

Go vet doesn’t report on structural issues - and those are far harder to work with/debug than code with the proper use of ternary operators (or even poor use)

Bad code is bad code no matter how you get there. 

--

[Andrew Klager]

> Is this so bad?

Yes, it's horrible as you'll loose any type information you had.
Meaning the next thing you naturally had to do was type cast it, which isn't the nicest syntax to begin with.
By then it's probably more work than just using if / else

So what you're saying is that Go needs a ternary operator and generics? ;) But yeah, for assignment, you'd need a type specific operator, or you end up with an if else (or at least an if) to do a type assertion, which defeats the purpose... or just use if / else, agreed.

 

[Sam Whited]

On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”

Yes.

What is "?"? If I've never seen that before I have no easy way to search
for that, and a random symbol me nothing about what it does. Go
specifically tries to stick to keywords because even if you've never
seen them before it's generally easier to figure out what they do (or to
search for them if you're not sure).

Not to mention that even if you do know what they do, that specific
statement isn't the problem. If you allow people to do that, they'll end
up trying to nest it 5 levels deep. Go tries not to give people the
tools to shoot themselves in the foot for some tiny perceived advantage.

—Sam

[John McKown]

On Thu, Apr 25, 2019 at 9:20 AM Sam Whited <s...@samwhited.com> wrote:

On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”

Yes.

What is "?"? If I've never seen that before I have no easy way to search
for that, and a random symbol me nothing about what it does. Go
specifically tries to stick to keywords because even if you've never
seen them before it's generally easier to figure out what they do (or to
search for them if you're not sure).

https://en.wikipedia.org/wiki/%3F:

ternary operator in C.

 

Not to mention that even if you do know what they do, that specific
statement isn't the problem. If you allow people to do that, they'll end
up trying to nest it 5 levels deep. Go tries not to give people the
tools to shoot themselves in the foot for some tiny perceived advantage.

—Sam

--

This is clearly another case of too many mad scientists, and not enough hunchbacks.

Maranatha! <><
John McKown

[ugo...@gmail.com]

FYI I recently posted a proposal for some unambiguous syntax which would give a lot of the value of ternary operators i.e. write the 5 line if-else block in the FAQ as a 1-liner, without the drawbacks, while IMO preserving the simplicity of the go language in approachability, readability and orthogonality.

Please review http://golang.org/issue/31659 and share your thoughts. 

On Wednesday, April 24, 2019 at 8:05:07 AM UTC-4, Mark Volkmann wrote:

> On Apr 24, 2019, at 6:22 AM, Robert Engels <ren...@ix.netcom.com> wrote:
>
> Though to the ops point, not sure why Go doesn’t have the ternary operator - which is pretty ubiquitous.

[Rob Pike]

I am pretty sure that the decision not to have ?: in Go was a unanimous decision by Robert, Ken and myself after almost no discussion. It is too easy to abuse, as the FAQ states.

-rob

[Mark Volkmann]

There are many counter-examples. What is the likelihood that someone who is not familiar with the "?" operator will be familiar with the operators for getting (*) and dereferencing (&) a pointer. And what is "<-"? Certainly people not familiar with Go will initially be confused by operators related to channels.

If you allow people to use pointers, will they use pointers to pointers to pointers to pointers?

--
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.

[lgo...@gmail.com]

Rob : how can it be abused if the compiler wont allow nested ? operators ??

[Jan Mercl]

On Thu, Apr 25, 2019 at 8:58 PM <lgo...@gmail.com> wrote:
>
> Rob : how can it be abused if the compiler wont allow nested ? operators ??

Rather easily. Just by fuzzilly mixing the otherwise purposely
distinct syntax of expressions and control flow.

[Thomas Bushnell, BSG]

I'm a big fan of the ternary operator in general. Maybe this is because I'm an old timey Lisper. A lot of the things people see as "abuse" or "too complex" are equally problems with || and &&.

This is also true for Jan's point: that ?: affects control flow by omitting execution sometimes. It would be lovely to say that in an expression, the subexpressions are always evaluated. But Go did the usual thing, declaring that && and || proceed conditionally.

If x and y are booleans, in fact, then "a ? x : y" is identical to "(a && x) || (!a && y)". We have all see boolean spaghetti. At the same time, I get sad whenever I see things like "if a { return x == y; } else { return false; }".

I don't mind Go's choice, however. It's a pragmatic and sensible choice: a bunch of people, for whatever reason, find && and || easy to reason about, and ?: annoying. Making code transparent is an important goal, so if you want to target those readers, avoid ?:. And a language like Go, designed to facilitate making things easy to understand over maximum economy of characters, sensibly omits ?:.

This fits with good Go style, which tends to avoid "else" more than a lot of other languages, making ?: standout all the more, with it's mandatory "else" clause. And, unlike && and ||, ?: works with all types, thus making it more pervasive when used.

Frankly, I would have preferred the Pascal approach here, which is more in line with what Jan says: decouple entirely control flow from syntax of expressions, and stop the experiment of having expression syntax imply control flow. That means that && and || might "short circuit" but also might not, and you would not be able to assume anything about the order of subexpression execution. But, at the same time, I have no quarrel with the pragmatic decision for Go to define those exactly instead.

[lgo...@gmail.com]

Rob:

Am I missing something ??

The proposed syntax 

test ? { 

} : { 

}  

with no-nesting allowed is equivalent to

if test { 

//.....

} else {

// .. 

} 

..The former is just a cleaner way of writing the latter

Any complaints regarding 'abuse' associated with the former equally apply to the latter

On Thursday, April 25, 2019 at 11:47:21 AM UTC-4, Rob 'Commander' Pike wrote:

[Dan Kortschak]

The difference is that the ternary operator is an expression and the
if...else is a statement. If you're only suggesting a syntax change,
then the difference becomes one of readability.

I'll ask again, how would you preclude nesting without making the
language more complex?

[Tyler Compton]

There are many counter-examples. What is the likelihood that someone who is not familiar with the "?" operator will be familiar with the operators for getting (*) and dereferencing (&) a pointer. And what is "<-"? Certainly people not familiar with Go will initially be confused by operators related to channels. 

 

If you allow people to use pointers, will they use pointers to pointers to pointers to pointers? 

Sure, every language feature has a complexity cost and a chance for abuse. However, the win for having pointers is, to me, a thousand times more significant than that of the ternary operator, so it helps outweigh the drawbacks that pointers introduce.

[lgo...@gmail.com]

To Kortschak and all others participating in this debate :

Please don't get hung up over my choice of symbol '?' . 

My choice of symbol '?' and ';' is causing people to equate my proposal with a proposal to adopt C's ternary operator in Go. This is not what I intended to propose.

My proposal  regarding ? test {...} : {.. } in is nothing more, nothing less than  a replacement for 

if (test) { ... } else {... }   i.e. 'if' and 'else' are replaced by symbols '?' and ';' ..

For example I propose that a statement like  ? (x >-1) { y=x; z= x*x } : { y=x*x; z= y  } compile in Go

EXACTLY THE SAME way that Go currently compiles the same statement with symbol '?' replaced by 'if' and ';' replaced by 'else' . Currently, neither C++, C nor Go will compile the above statement 

The  second part of my proposal called for allowing statements like x = (test) ? 1 : 0 to compile in Go.

C will currently  compile this statement but Go will not. But I stress again, I intended Go to compile this   

statement exactly the same way it compiles if (test) { x=1}  else { x=0 }  AND that no nested '?' symbols are allowed in a single assignment statement.

In short, I'm proposing a cleaner way to write Go 'if'  'else' statements,  nothing more, nothing less.

If anyone can offer a concrete example of how my proposed statement will cause problems in Go, just  replace my chosen symbol '?' with 'if' and symbol ';' with 'else'  and you'll have a statement that will currently compile in Go (and cause the same problems)

 ..  

[Robert Engels]

The problem is that Go already has if and else and else if (which would look really weird in your proposal)

Changing a word to a symbol does not enhance meaning -  it reduces it, and increases the learning curve. 

 Like I said, you will probably like Ada - lots of symbols there. 

--

[Dan Kortschak]

Please understand that my use of ?: in the proposed grammar is
irrelevant. Using the syntax proposed here leads to the same problem.

You have self contradictory claims below:

1. the change is only a swapping of 'if' => '?' and 'else' => ':' with
no semantic change: "My proposal  regarding ? test {...} : {.. } in

is nothing more, nothing less than  a replacement for if (test) {
... } else {... }   i.e. 'if' and 'else' are replaced by symbols '?'
and ';' .."

2. the change will result in conditional statements becoming
expressions: "second part of my proposal called for allowing

statements like x = (test) ? 1 : 0 to compile in Go."

1. and 2. are mutually exclusive since changing conditional statements
into conditional expressions is a sematic change.

In addition to this, there is a reduced readability for cases where
there are 'if { } else if { } else { }' chains (particularly if you
prohibit nesting as you want to.

The idea of prohibiting nesting is not feasible without introducing
special rules. Currently the grammar for conditionals is this:

IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt |
Block ) ] .

Which, if we simplify out the optional pre-condition statement we get
this:

IfStmt = "if" Expression Block [ "else" ( IfStmt | Block ) ] .

If we make the IfStmt into an IfExpr, to be useful, we end up with
along the lines of this (we need a new production that I am ignoring,
but you should get the idea):

IfExpr = "if" Expression ( Block | Expression ) [ "else" ( IfExpr |
Block | Expression ) ] .

And, IfExpr will need to be an Expression (otherwise there was no point).

So, how do you prevent the following (using current syntax, but with these new semantics).

```
if c == if test {
a
} else {
b
} {
fmt.Println("test is true and c == a or test is false and c == b")
} else {
fmt.Println("test is true and c != a or test is false and c != b")
}
```

(which is a nightmare to reason about already, even without new glyph-
based syntax)

The only way to prevent that is to special case the IfExpr, which
complicates the grammar and requires explanation of the special case,
and as I said before, ongoing go-nuts threads explaining why the
special case exists.

It's worthwhile trying to understand the arguments against the proposal
before you argue against the.

> > On Thu, 2019-04-25 at 13:38 -0700, lgo...@gmail.com <javascript:>

[Henry]

I disagree with the suggestion.

IF statement indicates a branching of execution path. It should be made to stand out so that when people are skimming through the code can immediately pick up these alternate execution paths. Changing it to a mere "?" will reduce its visibility. You have to read harder to pick up these alternate paths.

On Wednesday, April 24, 2019 at 8:05:31 AM UTC+7, lgo...@gmail.com wrote:

It sure would be nice if Go syntax allowed programmers to replace 

if ( test) {

...do sonething

} else {

..do something else

}

with 

? (test) {

//...do something

}

{

//..do something else

}

The ? operator can be anything the Go language team considers appropriate

[Mike Schinkel]

Marcus Low wrote:

datalen := removedKeyken // removedKeyken must have been int32 in your example.

if value != nil {

   datalen = len(value)

}

The issue with this is it makes two assignments when value != nil instead of just one.

[Mike Schinkel]

Andrew Klager wrote:

Is this so bad?

func ternary(cond bool, pos, neg interface{}) interface{} {

if cond {

return pos

} else {

        return neg

}

}

color := ternary( temp < 80, "blue", "red" )

The issue with that proposal is both true and false expressions are always evaluated. In (most?) other languages the non-relevant expression in a ternary expression will not be evaluated.

Your proposal would also typically requires type assertion, e.g.  

color := ternary( temp < 80, "blue", "red" ).(string)

Of course if Go were to add a built-in ternary() function that offered short-circuit expression evaluation and did not require type assertions, then IMO yes, it would be a good alternative to C++'s style ternary.

[Mike Schinkel]

On Thursday, April 25, 2019 at 10:20:54 AM UTC-4, Sam Whited wrote:

On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”

Yes.

What is "?"? If I've never seen that before I have no easy way to search
for that, and a random symbol me nothing about what it does. Go
specifically tries to stick to keywords because even if you've never
seen them before it's generally easier to figure out what they do (or to
search for them if you're not sure).

Given that, I am curious what your thoughts would be if this were possible in Go instead?
 
   color := if temperature > 80 then “red” else “green” 

And especially if this formatting were valid:

   color := if temperature > 80
      then “red” 

      else “green” 

[dja...@gmail.com]

Hi,

this is valid now:

color := func() string {
if temperature > 80 {
return "red"
}
return "green"
}()

https://play.golang.org/p/U7Lc92mq315 

[David Riley]

On Apr 26, 2019, at 2:12 AM, Mike Schinkel <mi...@newclarity.net> wrote:
>
> Given that, I am curious what your thoughts would be if this were possible in Go instead?
>
> color := if temperature > 80 then “red” else “green”
>
> And especially if this formatting were valid:
>
> color := if temperature > 80
> then “red”
> else “green”

That is pretty close to how Python added a ternary operator:

foo = bar if a==b else baz

More Pythonic, but same potential for abuse (no one is gonna stop you from nesting expressions).


- Dave

[Mike Schinkel]

David Riley <frave...@gmail.com> wrote:

same potential for abuse (no one is gonna stop you from nesting expressions).

Yes, but only assuming it were implemented as an expression.

However, if it were instead implemented as an “if-assignment" statement?

result := if temperature > 80 

   then "red"

   else "green"

Having it be a statement instead would not address what everyone wants, but it would solve the excessive verbosity of referencing “result” three times and having to explicitly declare its type, or having to assign to it only to have its value immediately overwritten:

var result string

if temperature > 80 {

   result = "red"

} else {

   result = "green"

}

And it would do those things without the downsides mentioned thus far in this thread. 

-Mike

P.S. And for me personally, it would help reduce the carpel-tunnel flareups I get from having to type so damn many shift-brace keystrokes.  :-)

[ffm...@web.de]

Here is the analoguous discussion concerning the ternary operator in Kotlin:

https://discuss.kotlinlang.org/t/ternary-operator/2116

After 168 posts to this thread where the thread creator did not want to accept that the language needs no ternary operator, the thread was finally closed by the admin.

[yvan....@gmail.com]

Agree with Mike Schinkel

if IF become functional  then useful

else if it is just a syntax change have absolutely no interest

On Thursday, April 25, 2019 at 10:20:54 AM UTC-4, Sam Whited wrote:

On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
> Are there really developers that find this unreadable?
>
> color := temperature > 80 ? “red” : “green”

Yes.

What is "?"? If I've never seen that before I have no easy way to search
for that, and a random symbol me nothing about what it does. Go
specifically tries to stick to keywords because even if you've never
seen them before it's generally easier to figure out what they do (or to
search for them if you're not sure).

|Given that, I am curious what your thoughts would be if this were possible in Go instead?
|

|  color := if temperature > 80 then “red” else “green” 

|And especially if this formatting were valid:

|  color := if temperature > 80
|      then “red” 

|      else “green” 

[Ian Lance Taylor]

In what sense is that an issue? If you are concerned about
performance, note that the compiler can eliminate the initial
assignment in the value == nil case if it is costly.

Ian

[Mike Schinkel]

I was assuming the compiler did not eliminate it. If it does then my point is moot.

-Mike

Sent from my iPad

[Michael Jones]

The last time there was a big thread about this, I explained how GCC added “value of brace block is value of last expression” to allow great power, and a fellow poster explained how this came into being with Algol-68. 

There is long history in these ideas, and much value, but Go specifically chose not to be an expression language. The limits of this are clear in the ++ statement vs c’s ++ operator. Huge, delicious power in the latter, tepid bit of economy in the former. It was a loss. The offsetting gain was believed to be in avoiding the four decades of confusion about ++ order of evaluation in function arguments and other situations. 

It’s natural to miss power long held. The Go experiment is about team efficiency in a far simpler language. It feels a great success to me despite the frustration of feeling muzzled. 

--
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.

--

Michael T. Jones
michae...@gmail.com

[Keith Randall]

On Wednesday, April 24, 2019 at 2:03:01 PM UTC-7, Kurtis Rader wrote:

On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski <mirtc...@gmail.com> wrote:

Here's the lore associated with the subject: Ken wanted ternary, Rob
and Robert did not. They overruled Ken (remember, early on all three
had to agree for a feature to go in). The end.

The number of frivolous and egregious abuse of ternary that I've seen
in _modern_ C code is too high.jpg

+100 to that sentiment. While the brevity of a ternary expression is  useful for trivial cases it tends to be abused. For your amusement/horror here are just a few, of a couple hundred, examples of ternary being abused in the AT&T AST (which includes ksh) source:

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/cmd/ksh93/edit/hexpand.c#L447

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/cmd/ksh93/sh/string.c#L344-L346

https://github.com/att/ast/blob/8504cd407846d192881a94d507333697f016a85a/src/lib/libast/include/sfio.h#L359-L360

https://github.com/att/ast/blob/8504cd407846d192881a94d507333697f016a85a/src/lib/libast/include/cdt.h#L313-L316

https://github.com/att/ast/blob/e770c77e9816e156c6df4a455e71b5f9fff79310/src/lib/libz/deflate.c#L597-L609

For those who don't want to follow those links this is the code from the first URL above:

lc_unicodeliterals = quote=='u' ? 1 : quote=='U' ? 0 : !!(ast.locale.set & AST_LC_unicodeliterals);

That one has the !! operator in it also, sweet twofer!

(It's the second link, not the first.)

 

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[charles...@gmail.com]

Ada originally followed BCPL and Pascal in distinguishing between commands (statements) and expressions, compared say to Algol68 which was an expression language.

BCPL had VALOF/RESULTIS to link the two realms. It also had a conditional expression (A -> B, C) with the same meaning as B's and C's later (A? B: C) [which is probably better syntax].

Neither Pascal nor Ada had conditional expressions, for different reasons.

Ada has since added both "if" and "case" as conditional expression forms (including "elseif"). There's a discussion in the 2012 Rationale:

http://www.ada-auth.org/standards/12rat/html/Rat12-3-2.html A big reason for introducing them was to support writing preconditions and postconditions.

there are quantifying expressions as well (ie, "for all", "for some"). Originally, they were 

special pragmas in the SPARK subset but were finally promoted to be part of the language.

Following the discussion above, I'd note though that one difference between (say)

if a > b {

   m = a

} else {

   m = b

}

   and

 m := b

 if a > b {

   m = a

 }

is that the former emphasises that the two cases (assignments) are mutually exclusive (m is either a or it is b), as opposed to (m is b unless it then becomes a),

not very interesting here but there can be more complex cases. 

In converting a C# program to Go I've had a few instances where converting to if/else was clumsier or even more obscure, often it seems in constructors converted to struct literals,

but in practice it's a minor point. As someone observed, sometimes little helper functions restore the flow and improve clarity (count!=0? total/count: 0) => avg(total, count)

[Michael Jones]

Agree completely. Despite my reasoned comfort with Go’s rationale I miss quite a few “but I want to express this algorithm beautifully for the ages” features. I don’t miss the ternary syntax but miss the natural way to say “it is an assignment, first, but subject to logic, second.” Same as I miss do...until/while, because the trivial workaround obscures the logic and I feel I’ve cheated the reader. Likewise, I lay out structs so the variable width parts (strings say) will be last so that the initializer will look as non-bad as possible after gofmt. I understand the trade off, but wish the literate style and beauty of mathematical typography had a better friend in go. 

--

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.

[whiteh...@googlemail.com]

imo a very important aspect of a language is enduring syntax stability.  Too many 'modern' languages lack even the most fundamental requirement of a solid Language Specification.  Well done Go!  And love or hate Java, that's what made it stable enough for it's massive and enduring success.

Go is the first language I've found as a worthy competitor.  Sure there are some things I miss, like ternary, non-local return, and a few things I'm not so keen of like panic vs runtime exceptions.  But I respect the designers choices, and I hope that Go 2 is a long way in the future :)

As language choice becomes more arbitrary, and transpilers more common, personal preferred syntax / language features may end up being handled like code formatting rules.  So In Peter++ I could then use all the syntax I like, transpile that to WASM or LLVM, and someone else working on that code transpiles it back into Gopher++ to make a change.

Just my thoughts,

Peter

[Mike Schinkel]

As language choice becomes more arbitrary, and transpilers more common, personal preferred syntax / language features may end up being handled like code formatting rules. So In Peter++ I could then use all the syntax I like, transpile that to WASM or LLVM, and someone else working on that code transpiles it back into Gopher++ to make a change.

That appears to be more of a bug than a feature to me, and a nightmare of incompatible source code. Imagine everyone on a team having their source code in their own flavor of a language? And I have yet to see a transpiler maintain 100% compatibility in both directions.

Sounds like pure hell to me.

IMO transpilers are a hack that come with lots of downsides. Also IMO developers use transpilers because those controlling the evolution of a language have not been responsive to the needs of their developers (I am mainly looking at CSS here, not Go.)

I for one pine for a day that will likely never come when transpilers are no longer needed for development (I am not referring to go generate here, but tools to input one language and output another.)

JMTCW.

-Mike

[DrGo]

I suggest that we first solve less controversial issues like the Israeli–Palestinian conflict.

[Jesper Louis Andersen]

I don't think there are developers who find it unreadable once they know the logic of that operator. However, if you don't know the rules, then it looks like black magic.

In large software developments, consistency beats convenience almost all the time. You can somewhat easily add another developer, if the notation rules are consistent. Whereas clever notational convenience costs for every developer you add to the project. Giving people a choice means you have yet another section in your style guide to understand and maintain.

The deeper observation is that in a language with two syntactic classes, statements and expressions, you can opt to have an if-like evaluation in the expression class, or you can omit it. Go does the latter, where C does the former. Of course, you can also define your language with a single syntactic class. In that case, the above example can be written

let color = if temperature > 80 then "red" else "green" in ...

This style is used in a large selection of languages, which people often call "functional languages". Though the lines of when something fits into the moniker is somewhat blurry.

On Wed, Apr 24, 2019 at 4:08 PM Mark Volkmann <r.mark....@gmail.com> wrote:

Are there really developers that find this unreadable?

color := temperature > 80 ? “red” : “green”

I know what you are going to say. People will nest them. But even nested usage can be readable when formatted nicely with one condition per line. Another alternative is to allow only unnested ternaries.

R. Mark Volkmann
Object Computing, Inc.

> On Apr 24, 2019, at 8:58 AM, Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Wed, Apr 24, 2019 at 3:48 PM L Godioleskky <lgo...@gmail.com> wrote:
>>
>> The lack of a Go ternary operator is at odds with Go's major theme of clean and easy to read syntax. Those who choose not to use the ternary operator can always resort back to Go's current 'if -else' or 'case' syntax. So Go syntax suffers no negative impact by adding the ternary op to its syntax list.  Those opposed to the ternary op should not be allowed to deny it use other Go programmers, that consider it useful.
>
> That's backwards. Those who has to read the code can no more chose not
> to decrypt the unreadable 4-level nested ternary operations instead of
> 5 if statements.
>
> And to follow on your "logic". If you add to Go even just 10% of what
> people consider useful, it will become a new C++, only much worse. And
> again by your very logic. Why we, that haven't chosen to code in C++
> in the first place, would be denied by others to use Go, when those
> others have C++ already at hand?
>
> Let everyone use the language he/she likes. Why ruin it for others
> instead of that by forcing Go to become the same as his/her other
> favorite language?

--
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.

--

J.

[David Riley]

On May 12, 2019, at 06:55, Jesper Louis Andersen <jesper.lou...@gmail.com> wrote:

I don't think there are developers who find it unreadable once they know the logic of that operator. However, if you don't know the rules, then it looks like black magic.

In large software developments, consistency beats convenience almost all the time. You can somewhat easily add another developer, if the notation rules are consistent. Whereas clever notational convenience costs for every developer you add to the project. Giving people a choice means you have yet another section in your style guide to understand and maintain.

The deeper observation is that in a language with two syntactic classes, statements and expressions, you can opt to have an if-like evaluation in the expression class, or you can omit it. Go does the latter, where C does the former. Of course, you can also define your language with a single syntactic class. In that case, the above example can be written

let color = if temperature > 80 then "red" else "green" in ...

This style is used in a large selection of languages, which people often call "functional languages". Though the lines of when something fits into the moniker is somewhat blurry.

As it happens, I did get to ask Ken Thompson about his reasoning when he presented at VCF East last weekend.

Ken said, as close to verbatim as my week-old memory gets, that they were “too hard to compile right without the possibility of introducing subtle bugs”. I didn’t press further, because there were plenty of people in line to talk to him and I didn’t want to be rude; my assumption is that he was talking about either order of expression execution, or the difficulty of lumping the subexpressions together. He definitely didn’t have anything to say about their potential for abuse or about them being confusing to new programmers, but then we also didn’t talk long.

Just adding that since I said I’d ask about it a few weeks ago.

BTW, the video of his keynote chat with Brian Kernighan is not to be missed; I was working the audio, so sorry about Brian’s levels, but he was feeding back so I couldn’t turn him up any louder: https://m.youtube.com/watch?v=EY6q5dv_B-o

- Dave

[lgo...@gmail.com]

Dave: Thanks for pursuing this issue and reporting back. 

Given the extent of responses to the original question by the Go community (pro and con), hopefully those responsible for Go syntax will re-visit the issue and decide whether Go statement "if test then {.. } else { .. }"  prevents any possible abuse or confusion  that would occur if it were replaced with   ?test { ..} : { .. }

On Sunday, May 12, 2019 at 11:35:51 AM UTC-4, David Riley wrote:

[Michael Jones]

On Mon, May 13, 2019 at 7:46 AM <lgo...@gmail.com> wrote:

Given the extent of responses to the original question by the Go community (pro and con), hopefully those responsible for Go syntax will re-visit the issue and decide whether Go statement "if test then {.. } else { .. }"  prevents any possible abuse or confusion  that would occur if it were replaced with   ?test { ..} : { .. }

 

It is inconceivable that "if test then {.. } else { .. }" will be replaced with "?test { ..} : { .. }" just as it is to consider changing red octagonal stop signs to blue ovals. A massive, omnipresent change (such as stop signs, power outlet plugs, which side of the road to drive on, programming paradigms now natural to tens of millions of people, etc.) needs an enormous motivation to be undertaken voluntarily--major problems that must urgently be solved in the new way. Nothing in the email here suggests anything more than personal preference and that is far too weak for such a change even if the Go gods all liked it. This is a stewardship issue.

(speaking as a non-god, but speaking truth)

[David Skinner]

I consider this to be a non-issue. There are two ways of writing in a new language. 

• You can learn the language as defined.
• You can write it the way you like it and convert to what is required and then convert every one else's stuff to what you like. Go makes it fairly easy for competent programmers to adapt gofmt to work with variations in your source. I like the ternary and still use it but my Go code on GitHub says IF. For me it is a keyboard shortcut, and as the years go by, I do it less. 

I agree with those who do not include the ternary, a consistant display and unambiguous standards are important.