Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New style check "mixing pointer and value receivers" #1337

Closed
nikolaydubina opened this issue Nov 30, 2022 · 3 comments
Closed

New style check "mixing pointer and value receivers" #1337

nikolaydubina opened this issue Nov 30, 2022 · 3 comments

Comments

@nikolaydubina
Copy link

nikolaydubina commented Nov 30, 2022

what?

similar to https://github.com/nikolaydubina/smrcptr

why?

Go has rules on how it can automatically select value and method receivers, which is complex and can lead to bugs.

Official Go guideline recommends:

Don't mix receiver types. Choose either pointers or struct types for all available methods.

Google Go style guide: https://google.github.io/styleguide/go/decisions#receiver-type

approach

Probably similar to https://github.com/dominikh/go-tools/blob/master/stylecheck/lint.go#L295

I can implement in free time too.

🙇🏻‍♂️

@nikolaydubina nikolaydubina added the needs-triage Newly filed issue that needs triage label Nov 30, 2022
@dominikh
Copy link
Owner

dominikh commented Dec 1, 2022

This is out of scope for Staticcheck on account of false positives; I don't think the guideline is universally true. It would certainly flag some exported APIs in the Go standard library.

@dominikh dominikh closed this as not planned Won't fix, can't repro, duplicate, stale Dec 1, 2022
@dominikh dominikh added new-check and removed needs-triage Newly filed issue that needs triage labels Dec 1, 2022
@ainar-g
Copy link
Contributor

ainar-g commented Dec 1, 2022

This wouldn't be as straightforward because some interfaces de facto require a value or a pointer receiver. Most notably, the (un)marshaling ones. See #911 and the issues mentioned there.

@nikolaydubina
Copy link
Author

nikolaydubina commented Dec 1, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants