I'd like to complete this work first; i.e., also implement an "gc/auto" importer which automatically decides whether to use installed packages or source (whichever is newer). And then make this "auto" importer the default importer. As a consequence, programs that just use the default importer wouldn't have to change at all.

Any objections?

Sounds great.

Per #11415 (comment) I think this should go forward with the "source" importer, rather than waiting for an "auto" importer.

CL https://golang.org/cl/37690 mentions this issue.

@josharian

It should also make cmd/vet/all a lot faster

I might be missing something here, but won't it do the opposite? i.e. make cmd/vet run slower?

See the numbers in https://go-review.googlesource.com/c/37691/.

cmd/vet/all currently has to do 'go install' in order to typecheck the files, which invokes cmd/compile, which is (unsurprisingly) heavier-weight than go/types. For cases in which the relevant packages have already been compiled, using the installed object files will be faster. That will remain the default for cmd/vet.

Thanks for the link: I understand the context now.

For cases in which the relevant packages have already been compiled, using the installed object files will be faster.

That's what I was getting at. My concern here was that for situations where packages are up to date there would be a needless hit by vet being moved over to the source importer (the exact use case of the "auto" importer)

... That will remain the default for cmd/vet.

Thanks for clarifying.