I wonder: why not just accepting interfaces as contracts (a subset), e.g. literally allowing
func Foo(type T fmt.Stringer)(T) T
and allowing runtime values of type contract, e.g.
contract SignedInteger(T) {
T int, int8, int16, int32, int64
}
func Foo(x SignedInteger) bool { return x > 0 }
i.e. decoupling the runtime boxing vs the compile type parameter resolution from the "interface specification language".
I do understand that the need for the new "contract" syntax becomes apparent when you have contracts over multiple variables, but that doesn't mean in the single type variable degenerate case there is no overlap. Perhaps embracing that overlap would help people understand more quickly where the actual difference is (in the way types and function signatures uses them, rather than what operations they describe)
I do understand that the need for the new "contract" syntax becomes apparent when you have contracts over multiple variables, but that doesn't mean in the single type variable degenerate case there is no overlap. Perhaps embracing that overlap would help people understand more quickly where the actual difference is (in the way types and function signatures uses them, rather than what operations they describe)