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: type parameter objects are not consistent across method signatures #48795

schroederc opened this issue Oct 5, 2021 · 2 comments


Copy link

@schroederc schroederc commented Oct 5, 2021

What version of Go are you using (go version)?

$ gotip version
go version devel go1.18-0d65c272c9 Fri Oct 1 18:18:46 2021 +0000 linux/amd64

What did you do?

type GenericSlice[T any] []T

func (g GenericSlice[T]) Print() {
	for _, v := range g {

func (g GenericSlice[X]) F() {}

What did you expect to see?

The type parameter in method signatures for a generic type should refer to the declared type parameter in the type declaration.

What did you see instead?

The go/types package yields a different types.TypeParam for the Print method's type parameter (T₂) vs the type declaration's (T₁). This makes it difficult for tooling to recognize that they are the same type parameter with the same constraints without extra bookkeeping.

The compiler also allows for an arbitrary new identifier referring to the generic type in the receiver (as in the X₃ type parameter for F). This seems like syntax that should be disallowed per Go's usual styling.

Copy link

@mknyszek mknyszek commented Oct 5, 2021


Copy link

@mdempsky mdempsky commented Oct 5, 2021

I think the first half of the issue is a duplicate of #45935.

The second half is consistent with the fact that parameter names aren't relevant to typing. E.g., there's no requirement that receiver parameters are all named the same.


@mdempsky mdempsky closed this Oct 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants