>I'm glad there are not such compiler flags.
Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L...
> Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
Yeah, I don't want being forced to use a dozen of flags just to compile a hello world program. Nor I do what to see various warnings that nobody really care about. It should fail or succeed. I prefer basic/minimal API that I can build upon not a kitchen sink approach. I think that's what makes Go a great ecosystem compared with many others. Compare the current Go compiler with various C++ compilers and you understand what I mean.
To sum it up you may use separate tools to do various magic things (i.e. goimports), they do not need to obey the Go1 compatibility rules. The issue is not that big to warrant a compiler flag.
This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import.
edit- how does a tool like this sound?
* If it sees an unused import, it comments it out
* If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it.
* It can run in a "check for commented-out imports" mode, so that commit hooks can reject such a state.
I guess (making some assumptions about go's import semantics) this would avoid the ambiguous name problem; it would mean you avoid having to edit both the import and the usage at the same time; and it makes it easy to tell if a file should be cleaned up.
Maybe it would cause issues if you're trying to choose between two libraries which both provide the same symbols?
> var _ = unusedImport
This is what the devs suggest as an alternative to having a compiler flag to turn off the check.
But with a compiler flag, I can easily discover the unused import when I build for production, simply by turning that flag off. By using the variable in a dummy way, I need to remember to go back and check for such things.
Presenting this as a way to address the problem feels like it's missing the point.