I believe this is working as intended, but I'll leave the bug open for gri. There are legitimate cases where leaving the brace on that line makes sense.

Sadly gofmt should unify style and two styles proliferated already in our company due to this issue.
So I am very interested in the legitimate use cases here.

Any news here?

I'll have a look at this for 1.6. But it is not the most urgent issue.

[Reworded request title, but not saying whether it should happen.]

Too late for Go 1.6.

Gentle ping.

Not sure we're getting to this due to many higher priority items, but marked 1.7Maybe so we keep an eye on it. If not, we'll try to do a concentrated effort to address most (all) the open gofmt bugs in the future, as gofmt could use some love.

It's too late for Go 1.7 at this point. This is a purely cosmetic change; we're down to semantic release-blocking changes.

@rsc / @griesemer while I agree that it is too late for a CL, could we at least finish the strategic/aesthetic decisions about how this kind of code should be formatted?

Then collaboration on the technical implementation can be done by a wider group of developers.

Thanks!

@griesemer any progress on the aesthetics front here?

@nightlyone Generally, gofmt respects the line-breaks that exist already. In this case there isn't one after the last element. So arguably, this is "correct" as is. From a purely aesthetic point of view, if the first element of a composite literal element list is not on the same line as the opening '{', I'd put the '}' on a separate line as well.

Well, just encounter this now in go go1.7.4 darwin/amd64, so the code need to be like this:

user := model.Users {
  UserId: "BJg4Kj2HOe",
  Gender: constant.G_U,
  MobilePhone: mobilePhone,
}

the comma , at the last line, the one after mobilePhone is mandatory, a bit wried, but still acceptable.

Note that @mvdan actually implemented this in https://github.com/mvdan/gofumpt as one of the additional rules it supports. So it seems possible.

@mvdan could you give some implementation hints or contribute the solution back?

You can see the code here if you're curious. I don't really have any hints per se; I just tried to implement simple rules that better restrict how most people write good Go. Of course I'm happy to contribute back some of the rules if Robert wants, but note that they'll be more like reimplementations since gofumpt needs to alter a program before being fed to go/printer.