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

Closed
schroederc opened this issue Oct 5, 2021 · 2 comments
Closed
Labels
FrozenDueToAge generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@schroederc
Copy link

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 {
		fmt.Println(v)
	}
}

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.

@mknyszek mknyszek added generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 5, 2021
@mknyszek mknyszek added this to the Go1.18 milestone Oct 5, 2021
@mknyszek
Copy link
Contributor

mknyszek commented Oct 5, 2021

CC @griesemer @mdempsky @danscales

@mdempsky
Copy link
Member

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 as completed Oct 5, 2021
@golang golang locked and limited conversation to collaborators Oct 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants