cmd/gofmt: Anonymous field could be placed in the 2nd column of a struct

[Kroc]

What version of Go are you using (go version)?

go version go1.7 windows/amd64

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\PROJECTS\Go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

What did you do?

What did you expect to see?

What did you see instead?

[quentinmit]

I suspect it's being placed in the first column because while it's called an anonymous field, it's actually named rune (as well as being type rune).

[griesemer]

I'm going to re-open this. I think the suggestion is quite reasonable and syntactically it makes sense (but @quentinmit has a point, too). Not saying that I will do anything about it yet, but I want to think about this a bit.

[Kroc]

Oh, cool. Thanks. There's a whole variety of ways to look at it, so I can understand opinion on where such a thing should go is going to differ for each person. I see the columns as 'name' and 'type', and so it makes logical sense to me that a name-less field should be lined up that way. The other side of the coin is that a nameless type uses the type as the name; ergo -- it's a name and belongs in the first column.

Last but not least, you can write the type twice as a workaround:

type thing {
    rune    rune    // a character
``

[griesemer]

@Kroc This is not field with a nameless type, it's a field w/o an explicit field name. That is, rune in this case is the type. The work-around that you describe may work here (embedding of a predefined type w/o methods), but generally this is not correct for any type as the semantics of the struct change.

[Kroc]

Excuse my ignorance, I'm extremely new to Go still :S