> "Unused vars are warnings" is not a possible opinion for go, period. It's also not a possible opinion for go tooling like 3rd party linters.
Right, but that doesn't mean that Go doesn't have an opinion about unused variables. Go's opinion is that they are compiler errors.
> my point is that it's not a design choice but a side effect of choosing "we don't have compiler warnings".
What makes you think that? I don't think "we don't have compiler warnings" was behind the choice to make unused variables a compiler error. It seems like a deliberate design decision on the part of the Go team.
> Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.
> There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (Conversely, if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
So I comment out a line or move around some code and want to quickly run it, or run the tests, whatever. This results in a cascade of either removing more and more lines and imports, or not only renaming to _ but also changing := to =.
This is of course the usual golang gaslighting. "It was easier to implement" becomes a "deliberate design decision".
There are tons of things that linters warn about (today), that should have been errors too by their logic.
Edit: my point is that it's not a design choice but a side effect of choosing "we don't have compiler warnings".