cmd/gofmt: Unexpected formatting multiline functions in struct literal

[andrewhare]

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

go version go1.9.2 darwin/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/drew/go"
GORACE=""
GOROOT="/usr/local/opt/go/libexec"
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/g3/0kqyss7j5zj0dj3gdkz2m9lw0000gn/T/go-build269266413=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

Run gofmt on the following code:

package main

type x struct {
	i        int
	someFunc func()
}

func main() {
	_ = &x{
		i: 1,
		someFunc: func() {
			_ = 1
			_ = 2
		},
	}
	_ = &x{
		i:        1,
		someFunc: func() {},
	}
}

What did you expect to see?

package main

type x struct {
	i        int
	someFunc func()
}

func main() {
	_ = &x{
		i: 	  1,
		someFunc: func() {
			_ = 1
			_ = 2
		},
	}
	_ = &x{
		i:        1,
		someFunc: func() {},
	}
}

Notice the first struct literal, that the value for i is indented to match someFunc as it is in the second literal.

What did you see instead?

The file remains unchanged. This seems to only happen when a multiline function is declared inline.

[bradfitz]

Sorry, gofmt is not soliciting change requests at this time. It's basically frozen.

I'll backburner this (milestone "Unplanned") for possible future consideration in a batch with others.

[mvdan]

For the record, I believe that what happens here is that two field values are not aligned if one of them is a multi-line composite literal itself.

So I think this is by design. If you take it to the extreme, this keeps alignment from potentially jumping tens or hundreds of lines past a composite literal, which could be very confusing.

Simply keeping alignments in this case would be a bad idea in my opinion, but perhaps this can be considered in a gofmt redesign along with other imperfect rules such as the "align fields values as long as the names are not too different in length" heuristic.

/cc @griesemer