Sorry, gofmt is not soliciting change requests on its format at this time. Gofmt made a set of choices at one point, and everybody agrees to live with them, even if everybody might take issue with different individual choices. (as Rob says: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s) For Go 2, @griesemer may trawl through the issue tracker for all old gofmt style request bugs.

Gofmt made a set of choices at one point

Yes, but that was many years before type aliases existed :)

That’s true but the formatting follows what var groupings does:

var (
	v1            int
	v222222222222 = 42
	v3            int
)

So it’s consistent. Changing one (type grouping) would arguably warrant changing the other (var groupings), which we aren’t planning to do.

Sorry, gofmt is not soliciting change requests on its format at this time. Gofmt made a set of choices at one point, and everybody agrees to live with them, even if everybody might take issue with different individual choices. (as Rob says: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s) For Go 2, @griesemer may trawl through the issue tracker for all old gofmt style request bugs.

This reads like you're referring to a years-old policy, so please correct me if that's wrong, but the 1.10 release contradicts this position. Not only did it change the gofmt format:

Two minor details of the default formatting of Go source code have changed. First, certain complex three-index slice expressions previously formatted like x[i+1 : j:k] and now format with more consistent spacing: x[i+1 : j : k]. Second, single-method interface literals written on a single line, which are sometimes used in type assertions, are no longer split onto multiple lines.

but the release notes go on to say that gofmt changes are to be expected from time to time:

Note that these kinds of minor updates to gofmt are expected from time to time.

And then discuss the ramifications:

In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended.

Was there a policy change after 1.10 shipped that I missed?

So it’s consistent. Changing one (type grouping) would arguably warrant changing the other (var groupings), which we aren’t planning to do.

Ah, good point! Seems clear it's intentional, then. Makes sense to me to keep this closed.

I should have worded it a bit differently.

If a change is small, then the proper mechanism would be to propose a change to gofmt via the proposal process.

But as this would carry over into other aspects separate from type aliases, I feel it’s too large a change to do at the moment for the reasons stated above.

As noted, @griesemer may look through old gofmt bugs for Go 2. When things get started in earnest I encourage you to re-open the issue. It’s just too early at this point.