See #7892

Ah, haven't noticed it has been discussed already. I still think it would be a very useful feature (java and C# reports that as a warning) but I understand the problem with implementing some interface methods partly and getting way too much useless reports.

What about having a rulefile for specifying what should be reported and what not? Like tslint does have for example https://palantir.github.io/tslint/rules/

Or some way to silence the false positives like: _ = key ?

What about having a rulefile for specifying what should be reported and what not? Like tslint does have for example https://palantir.github.io/tslint/rules/

I believe that traditionally rules that do not satisfy the three vet criteria (Correctness, Frequency, Precision) have been outright rejected, instead of being added but as an option as you suggest. Vet is meant to be a reliable tool that requires no configuration.

Or some way to silence the false positives like: _ = key ?

"Few false positives" means "few false positives", and not "false positives are okay as long as they can be silenced in some way". Almost every false positive can be silenced with the addition of some ugly code; I don't think this is desirable.

Those are just my personal opinions; but given that this was rejected in the past I'm not sure it will be reconsidered now.

It's a matter of opinion. One could say we have arguments in functions because we need them in the internal function algorithm and say, that declaring function argument and not using it is a bad practice (like importing a package and not referencing it).

I understand that one may occasionally need to have unused arguments to maintain backward API compatibility, but in those cases they can explicitly reference them by "_ = ..." like we do for unused imports.

govet could have saved me from making this mistake, unfortunately it only helped me once, when I was learning go and wrote a structure tag wrongly.

It would be helpful to know the opinion of more contributors.

Rob decided against this in #7892, and he is the ultimate arbiter of what goes into cmd/vet, so I going to close this.

I agree with this particular decision; I don't see a clear way to address the many false positives such a check would generate.