Skip to content
This repository has been archived by the owner on May 9, 2021. It is now read-only.

Check for inconsistent receiver types #489

Closed
rcorre opened this issue Apr 23, 2020 · 1 comment
Closed

Check for inconsistent receiver types #489

rcorre opened this issue Apr 23, 2020 · 1 comment

Comments

@rcorre
Copy link
Contributor

rcorre commented Apr 23, 2020

https://golang.org/doc/faq#methods_on_values_or_pointers says:

If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used

Would it be reasonable to have a rule for this? It is particularly important for types that contain fields for which copying breaks a contract, like atomic.Value. If I've defined functions of Foo to be pointer receivers specifically because Foo contains an atomic type, I'd want a warning if someone acidentally adds a function with a value receiver.

@mvdan
Copy link
Member

mvdan commented May 8, 2021

Thank you for submitting this issue! As per golang/go#38968, we are freezing and deprecating golint. There's no drop-in replacement to golint per se, but you should find that Staticcheck works well in encouraging good Go code, much like golint did in the past, since it also includes style checks. There's always gofmt and go vet too, of course.

If you would like to contribute further, I'd encourage you to engage Staticcheck's issue tracker or look at vet's open issues, as they are both actively maintained. If you have an idea that doesn't fit into either of those tools, you could look at other Go linters, or write your own - these days it's fairly straightforward with go/analysis.

To help avoid confusion, I'm closing all issues before we freeze the repository. If you have any feedback, you can leave a comment on the proposal thread where it was decided to deprecate golint - though note that the proposal has been accepted for nearly a year. Thanks!

@mvdan mvdan closed this as completed May 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants