While exploring the tip generics implementation, I attempted to determine if I could express "precise numeric conversions" (conversions that cannot cause overflow or loss of precision, such as int8 -> int16, but not the reverse).
I would expect the instantiation to be valid if the To parameter is valid for any of the embedded constraints within the union. I would not expect that the To parameter would need to validate against all possible embedded constraints for the same reason that a type does not need to satisfy all of int8 | int16 simultaneously.
What did you see instead?
When attempting to run, I see:
go run main.go
./main.go:6:16: To does not satisfy I16Plus
The text was updated successfully, but these errors were encountered:
changed the title
Generics: Union of embeddings should not eagerly evaluate parametersOct 19, 2021
In your example code, I16 can only be implemented by a type argument that satisfies I16Plus. ConvertTo can be implemented by a type argument that satisfies Integer. If someone writes ConvertTo[int8] that is valid according to the constraint of ConvertTo. ConvertTo then tries to instantiate I16[int8]. But int8 does not satisfy I16Plus, so that instantiation will fail. Therefore, ConvertTo is not a valid interface, and the compiler reports an error.
I think you are suggesting that the compiler should ignore the union term I16[To] for cases where To does not satisfy the constraint of the I16 type parameter. That is not how the current proposal works. And it would be a very subtle change, similar to C++ SFINAE. I think that it would permit certain kinds of conditional type matching during instantiation. That is probably not a feature that we want in Go.
In any case, such a feature would require a new proposal, describing the exact change proposed. I'm going to close this issue because the compiler is behaving correctly according to the currently accepted generics proposal.