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 17:27 -0700, lgod...@gmail.com wrote:
> 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)
> 
> 
> 
>  ..  
> On Thursday, April 25, 2019 at 5:15:23 PM UTC-4, kortschak wrote:
> > 
> > 
> > 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? 
> > 
> > On Thu, 2019-04-25 at 13:38 -0700, lgo...@gmail.com <javascript:>
> > wrote: 
> > > 
> > > 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: 
> > > > 
> > > > 
> > > > 
> > > > 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 
> > > > 
> > > > 

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