Gofmt needs to allow newline-operator

[kevma...@gmail.com]

I apologize for submitting yet another go format "issue". I'm more so gauging the community on this idea. Furthermore, I ask that you understand I'm not sure if this type of code format has a proper name to it, I'm just calling it "newline-operator-chain" (in contrast to "operator-newline-chain").

...For the record the first time I saw this type of formatting was when I was using SQL Server Management Studio 2012. It had formatted its `select` statements in a similar way. Though I normally hate Microsoft's ways of doing things newline-operator chains look much cleaner. Enough talking, it's best I just show what I mean:

operator-newline chain

if Variable1 == true &&
    Variable2 == 5 &&
    MakeSureICan() {
// ...
}




LotsOfArgs(myArg,
    anotherArg,
    bonusArg,
    thisArgToo())

newline-operator chain

Much cleaner in my opinion.

if Variable1 == true
    && Variable2 == 5
    && MakeSureICan() {
// ...
}




LotsOfArgs(myArg
    , anotherArg
    , bonusArg
    , thisArgToo())

Why Go format needs this

Looks cleaner, looks simpler

I believe that the newline-operator chain formatting looks niced due to the lining-up of the operators. This is nice to Go programmers like myself who are obsessed with readability. For instance, one could much understand the purpose of each argument in a faster manner when scanning through newline-operator chains as the operation is specified before the argument. Compared to operator-newline chains where the reader must look at 2 separate lines to fully understand the role an argument plays in the chain.

Makes more mathematical sense

And I think is more suitable for the underlining "mathematical" nature of operators in the first place. A good chunk of *any* programming is math, thus any language should share as many aspects with math as possible. Forcing operator-newline chain formatting disobeys this property.

We'd see this in math:

   2
 + 4
 + 9
 - 1
----
  14

not:

   2 +
   4 +
   9 -
   1
----
  14

The latter (operator-newline) looks confusing and harder to follow, the readability is lacking. Which is why I think we need to allow the former (newline-operator) in Gofmt. 

In my opinion, I think Gofmt needs to disallow operator-newline to achieve the highest grade of readability.

[Ilia Choly]

Your code doesn't even compile.

[Max]

Indeed.

It's not just a matter of gofmt: the "implicit semicolon" rule of Go syntax is triggered at the end of this line
```
if Variable1 == true
```
causing it to be parsed as
```
if Variable1 == true;
```
Any operator in the following line arrives too late to change that.

So to implement what you propose, Go syntax rules would need to be changed.

While they are not set in stone, the added convenience of your new syntax
is probably too small to justify a language change (just my opinion - feel free
to propose such a change to Go developers)

[Ian Lance Taylor]

On Thu, Oct 31, 2019 at 1:49 PM Max <massimilia...@gmail.com> wrote:
>
> It's not just a matter of gofmt: the "implicit semicolon" rule of Go syntax is triggered at the end of this line
> ```
> if Variable1 == true
> ```
> causing it to be parsed as
> ```
> if Variable1 == true;
> ```
> Any operator in the following line arrives too late to change that.
>
> So to implement what you propose, Go syntax rules would need to be changed.
>
> While they are not set in stone, the added convenience of your new syntax
> is probably too small to justify a language change (just my opinion - feel free
> to propose such a change to Go developers)

I doubt we would change the semicolon insertion rule at this point in
time. But if you do want to propose a change, make sure that the new
rule is unambiguous and is purely lexical. The rule that Go uses was
based on poor experiences with the way that Javascript handles
semicolon insertion.

Ian

[mr.sa...@gmail.com]

I suppose the change I'm going for is a semicolon won't be inserted if the next line starts with an operator.

That seems to make pretty strait forward sense as no line will start with an operator in the first place.

[Ian Lance Taylor]

On Thu, Oct 31, 2019 at 5:06 PM <mr.sa...@gmail.com> wrote:
>
> I suppose the change I'm going for is a semicolon won't be inserted if the next line starts with an operator.
>
> That seems to make pretty strait forward sense as no line will start with an operator in the first place.

The rule can't be that simple. It's valid Go to have a line that
starts with a unary operator:

func SetToZero(p *byte) {
*p = 0
}

Ian