4 ms·

So I am a bit unclear on this from the proposal. Composing contracts is a slightly more verbose fix for allowing multiple contracts for a given type (just make

So I am a bit unclear on this from the proposal. 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.

monkeyfacebag 7y ago
I think you're correct and I misread that part of the spec. That does seem to be an important limitation.
msbarnett 7y ago
> Maybe I'm misunderstanding though. As I read it, while you can't do: func Bar(type B setter, S stringer)(box B, item S) {...} directly, you accomplish the same thing via contract SetterStringer(B, S) { setter(B) stringer(S) } func Bar(type B, S SetterStringer)(box B, item S) {...} 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.
- samprotas 7y ago
  This is a good point. 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.
  - msbarnett 7y ago
    I’d be very interested in that as well, and I agree it seems verbose simply for the sake of maintaining a one-one func-contract correspondence. Maybe there’s some trade-off I’m not seeing here, though.

monkeyfacebag 7y ago

I think you're correct and I misread that part of the spec. That does seem to be an important limitation.

msbarnett 7y ago

> Maybe I'm misunderstanding though. As I read it, while you can't do: func Bar(type B setter, S stringer)(box B, item S) {...} directly, you accomplish the same thing via contract SetterStringer(B, S) { setter(B) stringer(S) } func Bar(type B, S SetterStringer)(box B, item S) {...} 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.

samprotas 7y ago
This is a good point. 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.
- msbarnett 7y ago
  I’d be very interested in that as well, and I agree it seems verbose simply for the sake of maintaining a one-one func-contract correspondence. Maybe there’s some trade-off I’m not seeing here, though.