-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
go/types, types2: better error message for failing type inference #39742
Comments
Thanks. This does seem like a problem with the type checker. |
Since no explicit type argument is passed to If an explicit type argument is provided, it works. Thus this is working as intended. Leaving open as a reminder that the error message could perhaps be improved. Not urgent. |
I am running into the same issue, but IIUC the explanation above does not seem to apply cleanly: https://go2goplay.golang.org/p/dVyEtkQ6oGD package main
type Foo(type T) interface {
Get() T
}
type foo(type T) struct {
}
func (_ foo(T)) Get() T {
var zero T
return zero
}
func Bar(type T)(_ Foo(T)) {
}
func main() {
{
var F Foo(int)
Bar(F) // allowed
}
{
var f foo(int)
F := Foo(int)(f)
Bar(F) // allowed
}
{
var f foo(int)
Bar(int)(f) // allowed
}
{
var f foo(int)
Bar(f) // not allowed: "type foo(int) of f does not match Foo(T)"
}
} (as a side note, if it somehow were to apply then it's extremely unfortunate that the simplest and most intuitive way of performing the Note that the same error is returned even if If it turns out this is not the same issue I can open a new one. |
@CAFxX I don't think that's the same issue. But I also don't think it is expected to work. The type inference in your final example is more or less the one described at #39049 (comment); the current algorithm doesn't support that. |
I suppose you meant to link a different issue. Regardless, if really the current design doesn't support it then please consider the bit above after the example as general user feedback on the design rather than on the implementation. If appropriate I can add this to #15292 (or file a new one?). |
Sorry about that, I meant to link to https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference-for-generic-function-arguments Thanks, the feedback is noted. I don't think it's time yet to file issues against the design draft. |
I believe the first example correctly reports an error now. |
The remaining error here is justified: package main
type (
iterable[T any] interface{} // empty constraint
binaryTree[T any] struct{}
)
func forEach[T any](t iterable[T]) {}
func main() {
v := binaryTree[int]{}
forEach(v) // error: type binaryTree[int] of v does not match iterable[T] (cannot infer T)
// arbitrary types T make this work - therefore type inference cannot infer the "correct" one
forEach[int](v)
forEach[string](v)
forEach[bool](v)
} Since arbitrary types may be used to satisfy the constraint, type inference cannot infer the "correct" type. |
What version of Go are you using (
go version
)?What did you do?
I felt upon this while toying with
go2go
.This is the minimal reproducible example illustrating what I think is a bug/problem.
https://go2goplay.golang.org/p/TBApH4WbSxk
What did you expect to see?
First, I think
int
should not have to be provided explicitly since it can be inferred fromv
.Also
v
does matchiterable(T)
sinceiterable
is the empty constraint.The text was updated successfully, but these errors were encountered: