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

go/types: method signatures not identical modulo receiver type parameter names #49912

Open
findleyr opened this issue Dec 2, 2021 · 5 comments
Open
Assignees
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Dec 2, 2021

Consider the following:

package p

// Basic defined types
type T1 struct{}
type T2 struct{}

// Identical methods
func (T1) M(int) {}
func (T2) M(int) {}

// Identical generic functions
func F1[P C](p P) {}
func F2[Q C](q Q) {}

// Generic types
type G1[P any] struct{}
type G2[Q any] struct{}

// Identical methods?
func (G1[P]) M(G1[P], G2[P]) {}
func (G2[P]) M(G1[P], G2[P]) {}

For the types in this code, the following holds (in pseudo go/types API):

  1. Identical(T1.Method(0).Type(), T2.Method(0).Type()) == true
  2. Identical(F1.Type(), F2.Type()) == true
  3. Identical(G1[int].Method(0).Type(), G2[int].Method(0).Type()) == true
  4. Identical(G1.Method(0).Type(), G2.Method(0).Type()) == false

(4) is false, because although we consider signatures identical modulo type parameter names, we don't consider methods identical modulo type parameter names. This may be minor, but seems incorrect.

@griesemer what do you think?

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Dec 2, 2021

I'm tentatively marking this as okay-after-beta1. Making a decision here could technically constitute an API change, but it seems very obscure and unlikely to be a problem. Others may feel differently.

@griesemer griesemer changed the title go/types: can methods on different generic receivers be identical? go/types: method signatures not identical modulo receiver type parameter names Dec 2, 2021
@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Dec 2, 2021

@griesemer and I discussed the following:

  • It's actually a bit odd that we don't consider receiver in Identical, since the identity of a method is more naturally the identity of the method expression, not the method value.
  • But this behavior has existed for a while, and may be useful (for example, looking for completion candidates in the Method API).
  • Our current treatment of receiver type parameters is inconsistent with function type parameters.

So we concluded that we should be consistent and ignore the names of receiver type parameters the same way we ignore the names of function type parameters.

@findleyr findleyr self-assigned this Dec 2, 2021
@toothrot
Copy link
Contributor

@toothrot toothrot commented Dec 8, 2021

Checking on this as a release blocker. Are there any updates?

@griesemer
Copy link
Contributor

@griesemer griesemer commented Dec 8, 2021

I believe we know how to fix this but haven't gotten around to it. This is primarily and issue for tools and shouldn't affect the beta.

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Jan 13, 2022

Will address this by next week.

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

Successfully merging a pull request may close this issue.

None yet
4 participants