What version of Go are you using (go version)?
$ go version go version go1.18rc1 linux/amd64
What did you do?
type T[T any] struct {} // okay
func (T[T]) Bar() {} // error: T is not a generic type
What did you expect to see?
Compiles okay.
What did you see instead?
Fails to compile.
Honestly, the behavior conforms to the tip spec:
The scope of an identifier denoting a type parameter of a generic function or declared by a method receiver is the function body and all parameter lists of the function.
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.
Comment From: ALTree
cc @griesemer
Comment From: griesemer
Hm. We're treating the receiver declaration like any other parameter list (including type parameter lists) for simplicity. I suppose we could say:
The scope of an identifier denoting a type parameter of a generic function or declared by a method receiver starts after the function name and ends at the end of the function body.
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?
Comment From: zigo101
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
Comment From: griesemer
@go101 The suggestion for the new scope rule I gave seems good enough: the scope of ordinary parameters (including the receiver) is the function body and type parameters are also declared in that block. The same block cannot have the same identifier twice.
Comment From: zigo101
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
Comment From: ianlancetaylor
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.
Comment From: gopherbot
This issue is currently labeled as early-in-cycle for Go 1.19. That time is now, so a friendly reminder to look at it again.
Comment From: griesemer
The corresponding proposal has been accepted. This issue now tracks the implementation.
Comment From: gopherbot
Change https://go.dev/cl/405754 mentions this issue: spec: adjust scope of function/method type paramaters
Comment From: griesemer
We didn't get to this for 1.19: the necessary change is not small given the way receiver type parameters are processed at the moment, and requires some re-engineering (tracked via #51343). Moving to 1.20.
Comment From: smowton
I note that this change appears in the Go 1.19 release notes (https://go.dev/doc/go1.19) despite not making it into Go 1.19
Comment From: griesemer
@smowton The actual spec change was made. This issue tracks the fact the the compiler doesn't follow the spec.
Comment From: smowton
Heh, that might be worth mentioning in the notes -- Go is now supposed to support this snippet... but there are no implementations of the spec yet :)
Comment From: inliquid
So release notes for go1.19 says this has been changed, however I see that problem still exists. This is the only opened issue with regard to it, another one locked.
Do above comments mean that change was made only to documentation and not implementation? Sounds weird. Why even mention it then?
Comment From: griesemer
The change was made in the documentation (spec) because we want the spec to be correctly describing the design (which it didn't). We haven't done the implementation yet, which requires #51343 first (and that one is non-trivial).
Comment From: griesemer
This depends on #51343. Moving to 1.21.
Comment From: griesemer
This depends on #51343 which moved to 1.22. Moving to 1.22.
Comment From: griesemer
This depends on https://github.com/golang/go/issues/51343 which moved to 1.23. Moving to 1.23.
Comment From: griesemer
This depends on https://github.com/golang/go/issues/51343 which moved to 1.24. Moving to 1.24.
Comment From: gopherbot
Change https://go.dev/cl/595697 mentions this issue: go/types, types2: add test for receiver type parameters