Contracts are a creative solution to generics, but they are also unexpected, weird, and possibly unnecessary.
Emily Maier's suggestion that contracts are superfluous is a good one. Interfaces in Go already serve as a kind of contract.
She has observed that, under the current proposal, it would be valid to copy-and-paste the function body into the contract. While the code would compile and presumably run. Go has already made design choices which limit the realm of the possible to keep developers from shooting themselves in the foot.
Contracts in Go only seem to be needed since code needs to assert at compile time that generic types can be used in built-in operations (i.e. that they satisfy a certain operational interface). Rather than introducing a new language construct, it seems more coherent to make these operational interfaces available as interfaces for the purpose of specifying a contract.
There are a lot of
| operator | proposed built-in interface name |
|---|---|
| a + b | sum |
| a - b | diff |
| a * b | prod |
| a / b | quot |
| a % b | mod |
| a / b | quot |
| a == b | eq |
| a != b | neq |
| a < b | lt |
| a <= b | lte |
| a > b | gt |
| a >= b | gte |
| a && b | and |
| a || b | or |
| !a | not |
| a & b | bwAnd |
| a | b | bwOr |
| &^a | andNot |
| a ^ b | xor |
| a << b | lshift |
| a >> b | rshift |
| &a | addr |
| *a | indir |
| a<- | rcvIn |
| <-a | rcvOut |