proposal: cmd/go: refine the default language version based on context

[bcmills]

Background

In https://groups.google.com/g/golang-dev/c/j3d8zuauJoY/m/gPOgpq_5DgAJ, @griesemer noted (emphasis mine):

Not everybody has switched to modules yet. We do know from surveys that the vast majority has (we estimate some 70-80%), but it is not the default mechanism. And even if everybody was using modules, introducing these changes would require .mod files to be adjusted to avoid breakages.

I agree with that assessment. However, I think there is a better default we could use in order to move forward with less churn: rather than having the Go language version used for dependencies track the maximum version supported by the Go toolchain (as it has in the past), we should have it default to a version that is likely to be compatible with existing code that was written for use in GOPATH mode.

Proposal

I propose that cmd/go should:

• If in module mode and the main module lacks an explicit language version, set it to the maximum supported language version (as cmd/go already does today).

• When compiling a package from a list of .go source files specified on the command line:

  • If in module mode and the working directory is inside of a module, use the main module's language version.
  • If in module mode but not inside of a module, use the maximum supported language version.
  • If in GOPATH mode, use the maximum supported language version.

• When compiling a package, either as a direct argument to the go command or loaded as a dependency of some other package:

  • If in module mode and the module containing the package has a go.mod file with a go directive, use the version indicated by that module's go.mod file.
  • If in module mode and the module containing the package does not specify an explicit language version (perhaps because it lacks a go.mod file), use Go 1.14 (or another version that has not removed support for any features introduced up to that point).
  • If in GOPATH mode, use the maximum supported language version.

Note that in all cases users can explicitly override the default by passing -gcflags=-lang=… either as an explicit argument or via GOFLAGS.

Rationale

Defaulting to Go 1.14 for packages outside of the main module in module mode maintains compatibility for packages written prior to the introduction of modules, even when they are loaded in module mode.

Defaulting to the maximum supported language version for file lists in module mode encourages users of standalone “script” files to either keep them up to date with language changes, or explicitly record the intended version in a corresponding go.mod file.

Defaulting to the maximum supported language version in GOPATH mode avoids the need to (imprecisely) scan the GOPATH tree (including vendor directories) looking for go.mod files, and seems the most likely to maintain compatibility for users “working at head” (which is generally what GOPATH assumes regardless). It is also consistent with the general non-reproducibility of GOPATH mode: if users want a reproducible build, they are encouraged to switch to module mode, and even if they do not they still have the option to set -gcflags=-lang=… explicitly or vendor in older versions of their dependencies.

See also #30791.

(CC @ianlancetaylor @matloob @jayconrod @dmitshur)

[mvdan]

I think this is a great idea. I almost suggested something similar in my already-too-long reply to Robert, but swapping 1.14 for 1.12 - the first version that introduced the concept of language versions. I imagine nothing should break by advancing those two language versions.

[thepudds]

@bcmills

If in module mode and the module containing the package does not specify an explicit language version (perhaps because it lacks a go.mod file), use Go 1.14 (or another version that has not removed support for any features introduced up to that point).

FWIW, I think this is important and I have suggested this in the past. (And I was just typing a response to the golang-dev thread to suggest it again, including using boltdb/bolt as an example -- that is a project that is solid code, has no go.mod, and is archived by the owner as a "finished" project where stability problems are "few and far between". That code should really keep working, even if it does not have a go.mod and even after features are removed from the language in the future).

[rsc]

Very important to note that, while at some point in the future we plan to make a backwards-incompatible version of Go, that is still aways off. Among other things it cannot happen until GOPATH is no longer used at all. So while you are right that we need to consider this before then, Go 1.15 is not going to be the "first break".

[rsc]

I suggest we put this on hold until we are ready to make a backwards-incompatible language change. We'll know more then.

[samthanawalla]

We discussed part of this in an email. It seems we agree upon using the containing main module's go version:

Current behavior

The Go version for a file passed in via command-line uses the local version.
e.g. $ go vet -x main.go
will set the Go Version to be the local version.

This happens in 3 places (maybe more):

1. vet
2. compiler
3. init.go

This ignores whether or not the file has a containing module.
e.g. current go version running is 1.23
-> main.go
-> go.mod (1.21)

$ go vet -x main.go
will set the Go Version to be 1.23

New behavior

As discussed in the email and in https://go-review.googlesource.com/c/go/+/567435 we have come to the decision to set the Go version to use the containing go.mod's version.
In the above example, $ go vet -x main.go
will set the Go Version to be 1.21

[rsc]

We ended up doing most of this proposal over the past few years as part of the toolchain work. The only part that's not done is the version for command-line .go files matching the containing module. That's clearly correct and important to do. No proposal needed for that.