Composing contracts is a slightly more verbose fix for allowing multiple contracts for a given type (just make a composed contract and specify that).
Using composed contracts, allowed:
func Foo(type T PrintStringer)(s T) {...}
I read this as, while a function can have multiple type parameters, only one contract can be specified in total.
Not allowed (function uses "setter" and "stringer"):
func Bar(type B setter, S stringer)(box B, item S) {...}
Maybe I'm misunderstanding though.
In other languages with parametric polymorphism, the real re-use comes in by allowing functions like Bar to be used for any combination of "constraint implementing" types.
so in practice it's basically the same thing, you just have to explicitly specify the contract the function conforms to via a composition of the two other contracts.
So maybe my concern is more a verboseness issue rather than expressiveness.
That said, it would be nice if there was some commentary on whether an implementation like Swift’s was considered and ruled out for some reason. As it reads now, I stand by my original comment that this restriction seems a bit arbitrary.
Composing contracts is a slightly more verbose fix for allowing multiple contracts for a given type (just make a composed contract and specify that).
Using composed contracts, allowed:
I read this as, while a function can have multiple type parameters, only one contract can be specified in total.Not allowed (function uses "setter" and "stringer"):
Maybe I'm misunderstanding though.In other languages with parametric polymorphism, the real re-use comes in by allowing functions like Bar to be used for any combination of "constraint implementing" types.