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
types2, go/types: the scope of a type parameter identifier in a method of a generic type is too large #51503
Comments
cc @griesemer |
Hm. We're treating the receiver declaration like any other parameter list (including type parameter lists) for simplicity. I suppose we could say:
This seems just as simple, perhaps even simpler. And it would avoid this arguably confusing error; even though I don't recommend choosing identifiers like this. But traditionally we have been paying attention to the ergonomics of scopes, so I think this warrants some attention. But it seems that we should be able to make this change later (1.19) as I can't see how it would invalidate programs that are now possible. (It's not an easy change, implementation-wise though, due to the way methods are represented: a method declaration corresponds to an instantiation of the method with the type parameters declared by the receiver which currently requires that the type parameters by the receiver are in scope in the receiver. This allows us to re-use a lot of code; but has also caused trouble. We were planning to change that part of the implementation independently. In any case, I wouldn't think this to be an impediment to making this spec change.) @ianlancetaylor @findleyr thoughts? |
More precisely, the scope of type parameter identifier in a generic type method declaration should be the current definition excluding the receiver generic type name part. The following error should be expected. The type parameter is declared firstly, then the value parameters (including receiver). func (T1 T[T1]) Bar() {}
// ./main.go:n:7: T1 redeclared in this block
// ./main.go:n:12: other declaration of T1 |
A similar problem: type C any
type _[C C] struct{} // cannot use a type parameter as constraint
func _[C C] () {} // cannot use a type parameter as constraint
func _(C C) {} // okay |
Yes, the scope of identifiers in a type parameter list is different from the scope of identifiers in a function parameter list. This is intended and documented. It's a necessary inconsistency, as we can't change function parameter lists, but we must permit forward references in a type parameter list. |
This issue is currently labeled as early-in-cycle for Go 1.19. |
The corresponding proposal has been accepted. This issue now tracks the implementation. |
Change https://go.dev/cl/405754 mentions this issue: |
Change scope rules per the accepted proposal #52038. Match prose for type parameters of type declarations. Fixing the implementation is tracked by #51503. Fixes #52038. For #51503. Change-Id: Iebd88a82c896b7b2e8520cd514ef6a2cc903e807 Reviewed-on: https://go-review.googlesource.com/c/go/+/405754 Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
What version of Go are you using (
go version
)?What did you do?
What did you expect to see?
Compiles okay.
What did you see instead?
Fails to compile.
Honestly, the behavior conforms to the tip spec:
However, I think , for a method of a generic type, the scope should begin after the name of the generic type in the receiver, instead of beginning the start of receiver part.
The text was updated successfully, but these errors were encountered: