Sorry, the gofmt format is pretty frozen, and personally I think once you had a field tag, there's enough information density there that it should be on its own line, as it already is.

I'm inclined to close this, but I'll let @griesemer decide.

I think the issue is that it’s a personal call, as you said. If an author chooses to put it on one line, then they’ve judged that it’s more readable that way. The formatter doesn’t reformat long lines presumably for this reason.

As @robpike has written (regarding variable names, at least), concision is an important aspect of readability, and one-liners like this are more concise. One-line function declarations are permitted, and useful for sort.Interface implementations, for example. Several of these one-liner structs (with a tag) in a row would similarly be more concise.

The formatter seems to break up lines mostly to eliminate semicolons. If that’s right (please correct me if I’m wrong), then these structs don’t fit that strategy.

I should note that it is possible for struct tags to be multiline:

type s struct{ f int `my
multiline
tag` }

Thus, "break up lines mostly to eliminate semicolons" is not the only heuristic the formater follows.

I agree with Brad that there's enough information density to be its own line.

@willfaught Note that #21952 allowed

interface{ m() }

to be on one line, but not

interface { m() /* foo */ }

the latter continues to be formatted as:

interface {
	m() /* foo */
}

If there's a tag on a struct field or a comment on a struct field or interface method, we want to continue highlighting it by making sure the field or method are on a separate line.

I'm going to close this as working consistently and as expected.

@dsnet I'd never seen a multi-line tag before. That's interesting.

@griesemer Fair enough. I can see how that's consistent with comments.

For what it's worth, I've never seen a general comment in a struct or interface type literal before, so it's unclear to me how useful that could be. However, one-liners like the following are useful in many ways:

var b, err = json.Marshal(struct{ F bool `json:"f"` }{F: true})

Currently, it would be formatted as:

var b, err = json.Marshal(struct {
    F bool `json:"f"`
}{F: true})

The first is clearer to me.

Thanks, all, for your consideration.