Imports, Aliases and Cycles

## The rule An import declaration introduces a name into the **file block** — the scope covering exactly one `.go` file. If your file imports `os` and no expression in that file mentions `os`, the compiler refuses to build it and prints something like: ./main.go:5:2: "os" imported and not used This is an error, not a diagnostic you can downgrade. There is no compiler flag, no pragma and no comment that suppresses it. Every other Go toolchain behaviour follows from that: the language has no "warnings" tier at all for this class of problem. ## Why an error rather than a warning Two reasons, both practical rather than theoretical. First, **warnings get ignored**. Once a build prints twenty of them, nobody reads the twenty-first, and the signal is gone. Go's position is that if something is worth telling the programmer, it is worth stopping for; if it is not worth stopping for, it does not belong in the compiler. Second, **imports are not free**. An import is an edge in the build graph. It pulls a package — and everything that package imports — into compilation and, for anything actually reachable, into the binary. A stale import that survived a refactor keeps a dependency alive that the code no longer needs, which shows up as slower builds, a larger binary, and a dependency list that misrepresents what the package really depends on. Keeping the graph honest at zero cost to the compiler is worth a small daily friction to the programmer. A third effect is social: because the rule is absolute, no code review ever argues about stale imports, and no lint configuration has to be agreed on. ## What the rule does and does not cover The same strictness applies to **unused local variables**: `x declared and not used`. It deliberately does not apply to: - package-level variables that nothing reads, - function parameters and named results, - struct fields, - unused constants and types. The distinction is that an unused import or an unused local is almost always either a leftover or a bug — you meant to use it and did not — whereas package-level declarations are frequently part of an API that other files or other packages consume, so the compiler cannot make the same judgment locally. ## The escape hatches There are exactly two, and only one of them is idiomatic. The idiomatic one is the **blank import**: `import _ "image/png"`. The underscore is the blank identifier, so the import binds no name; there is no name to be unused, and the compiler is satisfied. The package is still compiled, linked and initialised, which is the whole point of the form — it exists for packages whose value is a side effect of being present rather than an API you call. The scratch one, useful while debugging, is to reference the package once from a package-level declaration: `var _ = fmt.Println`. That keeps a named import alive while you comment out the code that used it. It is fine in a working tree and does not belong in a commit. Similarly, `_ = x` silences an unused local. Both are stopgaps, not style. ## Living with the rule The reason this is a footnote in daily Go rather than an irritant is tooling. `goimports` and the language server's organise-imports action rewrite the import block on every save: they delete what you stopped using and add what you just started using, grouping and sorting the block as `gofmt` would. Most Go programmers never type an import line by hand. ## The consequence worth understanding Because the compiler enforces this rule, you get a real guarantee: **every named import in a Go file is actually used by that file**. That guarantee is exactly why the blank import is a special case worth commenting. A blank import is the one import the compiler cannot check for you — nothing references it, so nothing breaks at build time if it is deleted. That is why the convention is to put a short comment on the line saying which side effect it is there for.