types2, go/types: the scope of a type parameter identifier in a method of a generic type is too large

[go101]

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.

[ALTree]

cc @griesemer

[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?

[go101]

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

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

[go101]

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

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

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

[griesemer]

The corresponding proposal has been accepted. This issue now tracks the implementation.

[gopherbot]

Change https://go.dev/cl/405754 mentions this issue: spec: adjust scope of function/method type paramaters

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

[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

[griesemer]

@smowton The actual spec change was made. This issue tracks the fact the the compiler doesn't follow the spec.

[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 :)

[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?

[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).

[griesemer]

This depends on #51343. Moving to 1.21.

[griesemer]

This depends on #51343 which moved to 1.22. Moving to 1.22.