Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bcmills opened this issue Jan 29, 2020 · 4 comments
Open

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

bcmills opened this issue Jan 29, 2020 · 4 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 29, 2020

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

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Jan 29, 2020

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

This comment has been minimized.

Copy link

@thepudds thepudds commented Jan 29, 2020

@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

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Feb 5, 2020

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 rsc moved this from Incoming to Active in Proposals Feb 5, 2020
@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Feb 12, 2020

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

@rsc rsc moved this from Active to Hold in Proposals Feb 12, 2020
@rsc rsc added the Proposal-Hold label Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.