proposal: go/types.ImportFunc

[adonovan]

I propose to add these two lines to go/types:

// An ImporterFunc is an implementation of the single-method
// types.Importer interface based on a function value.
type ImporterFunc func(path string) (*types.Package, error)

func (f ImporterFunc) Import(path string) (*types.Package, error) { return f(path) }

since we seem to keep typing them out everywhere else:

go/analysis/unitchecker/separate_test.go
293:type importerFunc func(path string) (*types.Package, error)

go/analysis/unitchecker/unitchecker.go
438:type importerFunc func(path string) (*types.Package, error)

go/analysis/passes/cgocall/cgocall.go
367:type importerFunc func(path string) (*types.Package, error)

go/packages/packages.go
1099:type importerFunc func(path string) (*types.Package, error)

gopls/internal/lsp/cache/check.go
1861:type importerFunc func(path string) (*types.Package, error)

internal/gcimporter/iexport_test.go
451:type importerFunc func(path string) (*types.Package, error)

internal/refactor/inline/everything_test.go
233:type importerFunc func(path string) (*types.Package, error)

@gri @findleyr

[mvdan]

I have a similar one here: https://github.com/burrowers/garble/blob/45b591d8eb924d05e7452c9c409e15a0a0b7775b/main.go#L158-L172

Note that it works with the ImportFrom method, and since ImporterFrom is documented as The types package does not call Import if an ImporterFrom is present, I make Import simply panic as I expect it to never be called.

Shouldn't that be the added API, e.g. as ImportFromFunc? Perhaps some of your use cases don't care about vendored packages, but in general I assume that the Import method should be treated as obsolete in favor of ImportFrom. For example:

// An ImporterFromFunc is an implementation of the single-method
// types.ImporterFrom interface based on a function value.
type ImporterFromFunc func(path, dir string, mode types.ImportMode) (*types.Package, error)

func (f ImporterFromFunc) Import(path string) (*types.Package, error) {
    panic("Import should never be called when ImportFrom is present")
    // or alternatively...
    // return f(path, "", 0)
}

func (f ImporterFromFunc) ImportFrom(path, dir string, mode types.ImportMode) (*types.Package, error) {
    return f(path, dir, mode)
}

[findleyr]

@mvdan I think the in the common case we already know the mapping of package path -> package, because we've loaded it from go/packages and/or are type checking a single package. Therefore I expect the API @adonovan proposes is more likely to be useful, as suggested by the cited reproductions.

[rsc]

If we accept #47487, then we won't need this. Perhaps it makes sense to muddle along with these unexported implementations for now.