Discussion of the Go Programming Language ()

Alexey Borzenkov | 7 Aug 2012 21:38

Curious oddity with gofmt

Hi,

I've been recently editing some go code, passing it thru gofmt and I
noticed an oddity. For example, code:

func main() {
	a := make([]byte, 16)
	b := len(a) - 1
	c := somefunc(1, 2, len(a)-1)
	d := sometype{1, 2, len(a) - 1}
}

Why is it that go *removes* spaces around minus operator in a function
call, yet it *adds* spaces when same minus operator is used within a
struct literal or a variable expression? It strikes me odd, because
it's extremely sore and unintuitive.

Best regards,
Alexey.

headers

Alexey Borzenkov | 7 Aug 2012 22:20

Re: Curious oddity with gofmt

On Tue, Aug 7, 2012 at 11:38 PM, Alexey Borzenkov <snaury@...> wrote:
> Why is it that go *removes* spaces around minus operator in a function
> call, yet it *adds* spaces when same minus operator is used within a
> struct literal or a variable expression? It strikes me odd, because
> it's extremely sore and unintuitive.

On the other hand, I tried patching go/printer for composite literals
to have the same logic as function calls and the patch like that would
not only be massive, literals become too tightly packed. So I guess
it's only odd when it's side-by-side like that, other times it's more
or less ok.

headers

Rodrigo Moraes | 7 Aug 2012 22:39

Re: Curious oddity with gofmt

On Aug 7, 4:38 pm, Alexey Borzenkov wrote:
> Why is it that go *removes* spaces around minus operator in a function
> call, yet it *adds* spaces when same minus operator is used within a
> struct literal or a variable expression? It strikes me odd, because
> it's extremely sore and unintuitive.

It removes the space when it is a sequence of statements, and adds a
space when it is a single statement. Click format here:

    http://play.golang.org/p/cSFJGCRuBI

I don't know if this is intended. Spaces (or no spaces) around
operators should be consistent everywhere imo, but that's not how it
is.

-- rodrigo

headers

Aram Hăvărneanu | 7 Aug 2012 23:10

Re: Re: Curious oddity with gofmt

It's a feature, grouping make it easier to see the underlying structure.

--

-- 
Aram Hăvărneanu

headers

Rodrigo Moraes | 8 Aug 2012 02:22

Re: Curious oddity with gofmt

On Aug 7, 6:10 pm, Aram Hăvărneanu wrote:
> It's a feature, grouping make it easier to see the underlying structure.

What doesn't make sense is that it seems inconsistent. When you type
this:

    _ = t{x: 1+2, y: 1+2}

It adds spaces. That shouldn't be grouped? What's the rule?

-- rodrigo

headers

Aram Hăvărneanu | 8 Aug 2012 16:16

Re: Re: Curious oddity with gofmt

This is grouped because grouping makes it easier to parse by humans:
	x := 2*3 + 4*5/3 + 2*(2+9)

This is not grouped because there's nothing ambiguous about it:
	y := 1 + 1

--

-- 
Aram Hăvărneanu

headers

Rodrigo Moraes | 8 Aug 2012 17:44

Re: Curious oddity with gofmt

On Aug 8, 11:16 am, Aram Hăvărneanu wrote:
> This is grouped because grouping makes it easier to parse by humans:
>         x := 2*3 + 4*5/3 + 2*(2+9)
>
> This is not grouped because there's nothing ambiguous about it:
>         y := 1 + 1

That makes sense. But how do you explain:

    http://play.golang.org/p/RlzjKnnrrf

?

-- rodrigo

headers

Paul Borman | 8 Aug 2012 19:28

Re: Re: Curious oddity with gofmt

The expression printer in go/printer/nodes.go supports "normal" and "compact" mode of displaying binary expressions with the operators * / % << >> & &^ and + - | ^. Normal has spaces, compact does not.

All operators of lower precedence (==, !=, &&, etc) always have spaces. In both function calls and assignments a comma is considered the first level:

_ = 1 + 2*3

_, _ = 1+2+3, 1+2*3

a(1 + 2*3)

a(1+2+3, 1+2*3)

With struct literals each element starts at the first level.

details are in go/printer/nodes.go

On Wed, Aug 8, 2012 at 8:44 AM, Rodrigo Moraes <rodrigo.moraes-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

On Aug 8, 11:16 am, Aram Hăvărneanu wrote:
> This is grouped because grouping makes it easier to parse by humans:
> x := 2*3 + 4*5/3 + 2*(2+9)
>
> This is not grouped because there's nothing ambiguous about it:
> y := 1 + 1

That makes sense. But how do you explain:

http://play.golang.org/p/RlzjKnnrrf

?

-- rodrigo