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
cmd/go2go: constraints that are type parameters #39723
Comments
I do not think this should be permitted. The type constraints should create a contract between the function caller and the function definition. If the function caller is permitted to set the constraint, then there is no contract. Also, note that we cannot deduce anything about permitted operations from this kind of constraint. So it does not permit any behavior in the generic function. All it does is give a way for the caller to constrain the type arguments--but the caller is already determining the type arguments anyhow. I can't think of anything that this would permit that is not currently permitted. So this seems both undesirable and unhelpful. |
Change https://golang.org/cl/239161 mentions this issue: |
Agreed. It turns out that the only reason this worked in some cases was due to a bug. Now fixed on dev.go2go. |
In particular, it cannot be a type parameter with an operational type that is an interface. Fixes #39723. Change-Id: Ia6b65eaecd472dd71b1c9f7631ce1872f06e5a6d Reviewed-on: https://go-review.googlesource.com/c/go/+/239161 Reviewed-by: Robert Griesemer <gri@golang.org>
We should be able to deduce that B is assignable to A, but I agree that the need for a type-list to make this work at all implies that it would not be very useful as a pointwise addition to the design. |
This is a design question: Should it be possible to use a type parameter as a constraint? For instance, should this be accepted:
A
is a type parameter, not an interface, but the constraint forA
ensures thatA
eventually is an interface. This case even appears to satisfy the type-checker. More complex cases fail at the moment.See also the 2nd example from #39711.
cc: @ianlancetaylor
The text was updated successfully, but these errors were encountered: