Go Contracts – Draft Design

Re:Go Contracts – Draft Design by msbarnett on Monday July 29, 2019 @06:15PM (#20560022)

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

[ Parent | on HN ]

Re:Go Contracts – Draft Design by samprotas on Monday July 29, 2019 @06:50PM (#20560298)

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.

[ Parent | on HN ]

Re:Go Contracts – Draft Design by msbarnett on Monday July 29, 2019 @07:37PM (#20560644)

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.

[ Parent | on HN ]