Robert Griesemer
Robert 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...
@smowton The actual spec change was made. This issue tracks the fact the the compiler doesn't follow the spec.
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...
This depends on #51343. Moving to 1.21.
This depends on #51343 which moved to 1.22. Moving to 1.22.
This depends on https://github.com/golang/go/issues/51343 which moved to 1.23. Moving to 1.23.
This depends on https://github.com/golang/go/issues/51343 which moved to 1.24. Moving to 1.24.
Slightly simplified reproducer: ```Go package p type S *S func f[R, T *R](T) {} func _() { var s S f(s) } ``` panics as described. But adding a `~`...
The handling of type element unification may not be quite right (see unify.go:566 ff.) Too late to fix for 1.23 as this is tricky and may introduce subtle bugs. Moving...
@taking and I looked at this some more. At the core of the issue we have the following situation. 1) Type inference correctly infers that `T ➞ S` from the...