proposal: enhance import directive to allow for alternatives on failure to better support promotion of experimental packages into the standard library

[jeking3]

This issue is a generic enhancement request for go.

Background

An experimental package called "golang.org/x/net/context" exists. This package was brought into the standard language in go 1.7 as "context". This is one example - it will happen again in the future many times over.

Problem

The import directive does not allow for alternatives or versioning to facilitate a smooth transition between experimental and official standard package status. While go is backwards compatible, this transition is not, and it has impacted many projects.

Proposal

Modify the import directive in the language to allow for a fallback position, for example:

ImportDecl       = "import" ( ImportSpec | "(" { ImportSpec ";" } ")" ) .
ImportSpec       = [ "." | PackageName ] ImportItems .
ImportItems      = ImportPath [ [ "or" ImportPath ] ... [ "silently" ] ] .
ImportPath       = string_lit .

for example:

    import "context" or "golang.org/x/net/context" silently

The two packages in this case have compatible APIs and therefore this single line of code would have spared hundreds of projects from having to deal with the transition of the context package into official status. The silently keyword would omit any warnings; without the keyword a warning would be emitted when an alternative is loaded.

Proof of Problem

1. Build Failing - Missing "context" package mock#116 (resolution: please update your go)
2. fix backwards compatibility with golang < 1.7 mock#118 (resolution: switched back to golang.org/x/net/context)
3. Go 1.7 uses import "context" grpc/grpc-go#711
4. Proposal: add context import path upgrade to go tool fix #17040 (tool proposal to help people move forward)
5. Context package and go 1.7 protobuf#217 (discuss when to make the switch)
6. Move to Standard library Context package go-kit/kit#420
7. package context: unrecognized import path "context" labstack/echo#899
8. x/tools/cmd/goimports: prefer golang.org/x/net/context #15471
9. The Apache Thrift project detects the go version at build time and inserts different files into the build to support <1.6 or >1.7 based solely on this package and imports "the right one".

There are many other examples of this.

[ALTree]

I've tagged this proposal but you'll definitely need to clarify the exact semantic of the change you are proposing to make this report a serious language change proposal.

Also, please note that Go tools almost never emit warnings, so I'm not convinced that the silently modifier will be well received.

[ianlancetaylor]

Since the concern is mainly for packages brought into the standard library, I think you need to explain why build tags are insufficient.

For example, for the context package, as long as you want to support versions of Go before 1.7, import "golang.org/x/net/context". That package is written to use build tags to make the right thing happen: if using Go 1.7 or later, you will in effect get the standard library "context" package.

[ianlancetaylor]

Closing in favor of build tags and the ongoing package versioning work (#24301).