CC @andybons

Friendly poke 🙂

In general, code should strive to be consistent. Having multiple names for something is in general discouraged. If you import and rename the same package as xpb and ypb, that's a bit odd.

But there may be cases where it does make sense to import a package once under its normal name and once under an alias. For example, net/http/request.go imports "net/url" as itself (url) but also as urlpkg. There is some code with variables named url that can still access urlpkg. But we still have the original name available for use in exported type definitions, to avoid having godoc that says "urlpkg.URL".

The situation seems nuanced enough that maybe it's not worth a CodeReviewComments change. Certainly we wouldn't want a golint that rejected net/http/request.go.

This can also come up in generated code. For example, goyacc adds import __yyfmt__ "fmt" to the generated code. The alias is there specifically so that user code can still import "fmt" without getting an error.

This seems like a valid use case for duplicate imports.

For example, net/http/request.go imports "net/url" as itself (url) but also as urlpkg [...] to avoid having godoc that says "urlpkg.URL".

If godoc generates confusing (or ugly) documentation in the presence of aliased imports, that seems like a problem with godoc, not the code. A user reading the documentation for a package should not have to dive into the code to figure out which package an identifier refers to. The author of the package should not have to go through contortions to render the documentation readable.

Note that go-critic dupImport diagnostic can catch this. (revive also does it via duplicated-imports check.)

If you're using golangci-lint, you can use it from that.

It seems like there is enough disagreement here that we should not be attempting to amend this wiki page, which too many people treat as "the law". There is also a good role for code reviewers here, to make sure changes match local conventions and are readable in general.

Based on the discussion above and the lack of consensus, this seems like a likely decline.

@rsc I've had this “fun” bug recently. I intended to write:

import (
	htemplate "html/template"
	ttemplate "text/template"
)

But for some reason (goimports?) wrote:

import (
	htemplate "text/template"
	ttemplate "text/template"
)

Which in turn meant that the HTML templates in my programme didn't receive the escaping it should have received. If there was a vet check against double imports, this wouldn't have happened. My personal vote is for this proposal, and for inclusion of a linter for this into go vet.

No change in consensus, so declined.

(If goimports really did change renamed imports that you'd written by hand, that's a bug and please file that separately. But I don't think it does that.)