Truly unfortunate. I don't write Go, but so often I comment out large swaths of code for debugging purposes and get warnings for unused variables and imports. If I couldn't simply ignore the warnings, I would not be a happy camper. It's funny to me that people call it a "hackers language", when it seems so restricting from afar.
Doesn't help when you remove chunks for testing purposes, but want to keep the imports around as you'll be adding them back immediately after and don't want to search for the right import again.
I think you missed the point of the comment - no matter if you're removing or adding imports, the tool (goimports) should do it for you automatically. It's easy to setup with any modern text editor (VSCode, emacs, etc)
What of when there are duplicate symbols with the same name? And this doesn’t help with unused locals. Also, another commenter pointed out that unused local functions don’t get flagged. Go authors probably realized that making people delete and restore entire function bodies during debugging was too much, but they could still convince people to be okay with deleting and restoring import statements and local variable definitions.
My experience with GoLand is that it manages to add back the right imports (notably with things like errors vs github.com/pkg/errors vs github.com/cockroachdb/errors, where they all share a package name and ~interface) but that might just be me getting lucky or not noticing changes.
You got lucky. And it still doesn't solve the problem of unused variables.
At the end of the day, it's a hair shirt. And no matter how many coping mechanisms people come up with, it's still a hair shirt.
Even the go authors had to put a limit on their madness. You'll notice that unused unexported functions don't cause compilation errors despite the fact that they, too, fall afoul of the original justification for this policy: 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, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity."
But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.
> But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.
while a pain, for unused variables, if it comes up, right under the declared variable, just add the line: _ = myVar. Bingo, now it is used. Gross, but works.
Looks like you're prepping for a PR? Good luck, in earnest; the import-in-import-out dance is like adding 8 seconds to every dev cycle.