This seems like it will bring quite a few false positives. Have you prototyped such a change, and seen what it finds in the Go tree?

Seems like the title should be "returning nil inside if err != nil" instead of "returning err inside if err != nil".

Here's a valid return nil from the stdlib. I agree this will bring a lot of false positives.

https://github.com/golang/go/blob/release-branch.go1.10/src/crypto/x509/root_darwin.go#L213-L225

This example is not what I suggest catching, because the if clause contains things other than return nil.

Other reasonable scenarios come to mind, for example:

• Getting io.EOF but returning nil, because it was expected
• Funcs whose return type isn't error (perhaps obvious, but this issue does not clarify that)
• Expecting an operation to fail, thus returning a nil error when an obtained error is non-nil

And there's also the can of worms that is errors that are always nil. This kind of check probably belongs in a tool that gives a human suggestions, and not a linter that gives warnings that must be accurate.

cc @robpike for a final decision, but I think the likely false positives from this make it not a good fit for vet.

cc also @dominikh in general for all things that don’t make it into vet. :)

Fails the precision criterion of cmd/vet/README.