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

[findleyr]

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]

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.

[findleyr]

@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.

[toothrot]

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

[griesemer]

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]

Will address this by next week.

[findleyr]

As discussed in #50887, we decided/discovered that the best course of action is to do nothing here, but to answer questions about method identity using instantiations with type parameters.