/ go Public
go/types, types2: explore "interleaved" type inference by combining function argument type inference with constraint type inference #51139
A change that should be done early in the 3 month dev cycle.
Issue is related to generics
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Issue is related to generic type inference
This is extracted from an old comment by @rsc on the behavior of type inference as described in the spec (and as currently implemented). Given the following code:
Type inference passes in separate phases of function argument type inference and constraint type inference: In the first phase (function arguments) the following matches are established:
S -> MyPtrand
T -> *int. At this point we have all type arguments and we're done. After instantiation of
Appendwe have the non-generic function:
MyPtris not identical to
Per the comment by @rsc, this could work if function argument type inference and constraint type inference were interleaved (and inference using typed function arguments would stop as soon as all type arguments are known).
In such an interleaved world, as soon as we have established the mapping
S -> MyPtrconstraint type inference would match
Tand establish the mapping
T -> MyPtr. At this point all type arguments are inferred and upon instantiation of
Appendwe would get:
Calling this version of
Appendwould work because the unnamed type
*intcan be assigned to the named type
It might even be possible to apply constraint type inference to constraints that don't have a single specific type: As soon as we have a type argument inferred from a function argument it could be matched against every specific type in the constraint.
The interleaved type inference behavior is more powerful in this specific case (and thus we could change this in a backward-compatible way).
@rsc, @ianlancetaylor, @findleyr for comments.
The text was updated successfully, but these errors were encountered: