-
Notifications
You must be signed in to change notification settings - Fork 18k
go/types, types2: type parameter order is significant when it should not be #40789
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
Comments
Here's something simpler to demonstrate the problem.
|
Thanks for this. Another case where the prototype type-checks too eagerly. This is a problem we need to solve in general in a real implementation (probably requires a two-phase approach). Addressing this should resolve a large number of bugs (not just with generics but elsewhere as well). |
Change https://golang.org/cl/331690 mentions this issue: |
The above CL fixes this issue for types2. The initial example still doesn't fully compile due to an unrelated error in the compiler. |
…or type bounds While at it, clean up code for collecting/declaring type parameters. For #40789. Change-Id: I0855137d5ee85c0ae2fa60d33b28c24a33132fbc Reviewed-on: https://go-review.googlesource.com/c/go/+/331690 Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
This was fixed in the type checkers by https://golang.org/cl/331690 in |
commit 722af87
The following program fails with the error "K does not satisfy comparable", in the
copyMap
function definition when AFAICSK
is declared correctly as having a comparable constraint.The text was updated successfully, but these errors were encountered: