When I'm debugging something, I don't want compiling to fail just because I've commented out the only line that uses the net/url package. If I temporarily modify a function call to use a literal instead of a variable so I can test an assumption, I don't want it to refuse to compile just because that variable is now "unused". The cascade effect of this can get quite extensive and annoying.

Same goes for exploratory programming, where I'm testing out ideas rather than writing production code. I expect my tools to get out of my way rather than play nanny.

I learned to always wrap the code with `if false {}` instead of commenting them out because of this very reason.

That doesn't give you nearly the same flexibility as commenting out, as if statements are not expressions, but epsilon can very well be. JS:

const value = getMainValue() + calculateAdjustment();

const value = getMainValue() // + calculateAdjustment();

goimports on save will change your life :)

Goimports breaks when two packages have the same local name, can't handle import name overrides, and doesn't solve the variable problem. My solution fixes everything.

Alternatively just add usages at top of package that have no real effects. This is experimental code after all! Never had problems with this, but yes, it's a bit different.

So many silly workarounds being suggested here. You should be able to pass a flag to accomplish this, anything else is simply annoying and drives away new users.

That's a feature!

You could have a flag, but we all know this is going to be abused. Seems devs have opted away from such, though it is understandably opinionated and require some thought.

In what way would it be abused? "To use this library, you must enable warnings in your build"? Yeah, that's gonna fly. If your code won't compile with default options, nobody will want to use it.

This is just a solution in search of a problem.

Isn't such types of shenanigans SOP in many communities?

Not against options per se, but can see the arguments against implicitly hiding alternative behaviour. Many compilers fail to be simple, performant and provide the right incentives.

Again, never had problems adding experimental code (// TODO: Remove), bootstrap-code, extra debug-info, etc. Ie. Why you should want to prefer refactoring.

It's not a feature, it's an annoyance. Don't use the flag in CI and don't allow merges until CI passes. It's not hard.

But then if you forget to take those bits out, you now have unused things in your checked in code, which is exactly what the compiler was trying to prevent!

The build flags approach is more comprehensive and safer, because it simply won't compile when you build without the -warnunused flag (for example in your ci trigger off your git repo).

> Why would you want unused imports or variables?

The main reason would be that they don’t actually matter and having to strip them out is a worthless pain in the ass when trying things out.

When actively developing code, it can be useful for warnings to go away. Get things to work, then make it tidy.