cmd/compile/internal/types2: inconsistent type inference involving anonymous interfaces #43056
Comments
I don't see why the type parameters have identical type. One is type |
The calls' value arguments |
I agree that either both of these calls of Unfortunately, we currently have an asymmetry in the unification algorithm: If one of the involved types is a defined type (here Since we started with In the 2nd case we start with In summary, unification produces the following calls: F[I](i, j)
F[interface{ Equal(I) bool}](j, i) It seems reasonable to postulate that if we enter unification with an underlying type of a named type to make it succeed, the inferred type should be the underlying type (here But then both calls in this example would fail (because instantiation fails). Alternatively, maybe the interface This problem only occurs with interfaces because those are the only types for which we can provide methods in the type literal; for all other types, we need a defined type to attach methods. There may be other work-arounds and changes to the inference algorithm that make this work "as expected". But is does seems accepting #8082 would solve this problem for interfaces. |
Change https://golang.org/cl/276692 mentions this issue: |
After review, the only non-superficial change was to delegate the call to under(...) to structuralType. Otherwise, update a few stale comments: + correct indices in the documentation for tparamsList + update smap->substMap in a few places + update type parameter syntax in a couple places I've spent a good amount of time reviewing this code, and it fundamentally LGTM (though I wish we didn't have to copy the logic from identical0). However, as demonstrated in #43056, this code is complicated and not always easy to reason about, particularly in the context of type checking where not all types may be complete. To further understand and verify this code I'd like to write more tests, but that must wait until the rest of the changes in go/types are imported from dev.go2go. Change-Id: Iabb9d3a6af988a2e1b3445cde6bc2431a80f8bfe Reviewed-on: https://go-review.googlesource.com/c/go/+/276692 Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
In the test case at https://go2goplay.golang.org/p/gEl3-egETB2, F(i, j) is accepted, but F(j, i) is not. Both of F's value parameters have identical type, so the behavior here should be consistent (either both accepted, or both rejected).
Based on my understanding from Robert (that type inference requires arguments to have identical type to the parameter, not mere assignability to it), I suspect the correct, consistent behavior is for both to be rejected.
Some more tests at https://go2goplay.golang.org/p/aVaXxBbK1j5. I plan to write a program to exhaustively generate test cases.
(My motivation for looking into this was adding type parameter support to rf, for type-polymorphic rewriting rules: rsc/rf#6)
/cc @griesemer @ianlancetaylor
The text was updated successfully, but these errors were encountered: