| > Do you have any reason to think that? E.g. documented or discussions at the time? This is directly from https://golang.org/doc/faq#unused_variables_and_imports """
The presence of an unused variable may indicate a bug, while unused imports just slow down compilation
""" Why do unused imports slow down compilation? Because that's how Go is designed. "It makes code good" is post-hoc validation of that. > Is that what you mean? Yes > If you mean "no, not silently ignore. Give a warning", then that runs into the (eyerolling) "the Go compiler doesn't have warnings. It runs effectively -Werror. It's eyerolling because it's clearly not true, as they've simply outsourced those second class warnings to govet and other tools. Yes. :) This is also how you'd find out the unused imports. The tools could even remove them for you. > importing and not using does not create the same behavior as not importing at all? In case of go it is the same behaviour: compilation stops. So it never bothers to import them anyway. > I don't want the compiler to make that choice for me. It already has made these and other multiple choices for you: - it refuses to compile valid code - it outsources a bunch of stuff to dozens of external tools that you still run, or are forced to run, or are supposed to run anyway. There's literally a whole parallel ecosystem in go because go generate exists. - and I can even quote the link from above: "Nowadays, most Go programmers use a tool, goimports, which automatically rewrites a Go source file to have the correct imports, eliminating the unused imports issue in practice. This program is easily connected to most editors to run automatically when a Go source file is written." The compiler made these choices for you. So, instead of a compiler doing its job, it requires you to run half-a-dozen or more tools just to make the compiler's job before it can even run on an otherwise absolutely valid code. > And Go is baking IWYU into the compiler. You may not like it, but it's not stupid. That's the other way around, isn't it? "'Include what you use' means this: for every symbol (type, function, variable, or macro) that you use in foo.cc (or foo.cpp), either foo.cc or foo.h should include a .h file that exports the declaration of that symbol." This means there are no implicit imports like some magical global function that's part of the standard library that the compiler just knows about. And, once again. The compiler knows about unused imports so it doesn't even have to include them. Just the fact that C++ or Python include every single thing they see an import for doesn't mean it's a good thing or that Go should do the same. Isn't it like compilers 101? Don't do more stuff than you absolutely have to do? Isn't it what (optimising) compilers ultimately do anyway: they throw away unused stuff from the generated code etc.? |
Why would it not? It needs to check the tree imported for side-effects. Like I said this is true for C++, C, and Python at least too.
> "'Include what you use' means this: for every symbol (type, function, variable, or macro) that you use in foo.cc (or foo.cpp), either foo.cc or foo.h should include a .h file that exports the declaration of that symbol."
The analogy doesn't work well because "import" in Go is both a replacement for "include" and for linker flags.
Needless imports is like adding needless .o files on your linker line. The linker cannot know if you meant to call those constructor sections.
My comparison to C and C++ were not in the compiler (includes), but in the linker.
> Isn't it what (optimising) compilers ultimately do anyway: they throw away unused stuff from the generated code etc.?
Yes, and I believe linkers can trim symbols that are not referenced by any code.
But they can't remove __constructor__ sections. Because they are referenced, and will run.
E.g. maybe you imported a package because it defines some flags, but you stopped using the flag. But some scripts still provide it.
Importing not being an error means that the flag exists. Did you mean that? Go forces you to be intentional.