proposal: cmd/gofmt: deprecate 'gofmt' in favor of 'go fmt'

[ialidzhikov]

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

$ go version
go version go1.12.7 linux/amd64

Does this issue reproduce with the latest release?

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

go env Output

$ go env

What did you do?

What did you expect to see?

Currently is gofmt and go fmt are both used in the community for formatting. go fmt runs gofmt -l -w on packages. The args for gofmt are system paths, for go fmt - packages.
Can't we just use go fmt with the full set of gofmt args and depricate gofmt?
At least for a newbies it's a little bit confusing gofmt vs go fmt - why there are 2 things that does appr. the same thing?

What did you see instead?

[julieqiu]

/cc @bcmills

[dpinela]

gofmt can be used as a Unix-style filter, which reads source code from stdin and prints the formatted source to stdout. go fmt currently cannot - invoking it without arguments formats the package in the current working directory - although I think that could be changed without breaking the latter use case.

At least in the abstract, I like the idea of merging the two or explicitly recommending one. It would, to some extent, parallel how go vet became the recommended way to invoke vet, rather than using go tool vet directly.

[bcmills]

CC @ianthehat @jayconrod

[mvdan]

I don't think this is a good idea; see @rsc's comment in a related issue.

I guess we could teach go fmt to behave like gofmt given some flag or knob, but there are still lots of programs and scripts out there that require gofmt. Would we simply break those?

It's also worth noting that gofmt is a relatively small and simple binary, while go fmt is part of cmd/go, which is a comparatively massive suite of tools, often including a compiler and linker.

[rsc]

Duplicate of #35258.