it looks like contracts are composable the same way interfaces are so I don't know how much of a limitation this will be in practice.

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.

> 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.

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.

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.

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