cmd/compile: different results between inferred generic type argument and explicit generic type argument #61741
Comments
|
CC @griesemer |
ianlancetaylor
added
TypeInference
ianlancetaylor
changed the title
|
This does look like a type-checking bug to me. The type inference code checks that it inferred the expected type, but doesn't consider the case of the inferred type being an inference type. But this doesn't seem like a major bug, and we should consider postponing a fix until 1.22 and 1.21.1. |
|
Simplified repro: package p
func f[T any](interface{ Encode(T) }, T) {}
type RuntimeObject interface{}
type KubeCodec struct{}
func (KubeCodec) Encode(RuntimeObject) {}
type Object struct{}
func _() {
f[RuntimeObject](KubeCodec{}, Object{})
f(KubeCodec{}, Object{}) // type Object of Object{} does not match inferred type RuntimeObject for T
}Inference trace: This is a (known) limitation of the current implementation: T₂ has been correctly inferred to be a RuntimeObject. But at the moment we require both types to be interfaces to avoid an order dependency. Related to #60933. |
|
Even simpler reproducer: package p
func f[P any](P, P) {}
func _(a any, i int) {
f[any](a, i)
f(a, i) // ERROR: type int of i does not match inferred type any for P
f(i, a) // ERROR: type any of a does not match inferred type int for P
}We can't address this with the current, relatively simple (but still plenty complex!) type inference approach. It's not clear that we should. There's always the option to provide an explicit type argument. Cases like these appear when the type argument is an interface. In many such cases, not using generic code in the first place may be the right choice (we already have polymorphism through the interface). Closing as not planned. |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
It is currently reproducing on the latest gotipplay
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
https://gotipplay.golang.org/p/sUrlIpN1rLa
Given a generic interface+function pair:
and a valid implementation of the above interface:
and the two calls below:
The generic type inference can correctly infer the type for WriteFile in the second case, and it matches the explicit type argument from the first call, but it still gives an error.
What did you expect to see?
I expect both of these lines to work:
What did you see instead?
The text was updated successfully, but these errors were encountered: