Some things that must be considered with this approach are:

• type conversions
• untyped constants
• for/range
• unary vs. binary operators
• index operations
• assignment operations

We actually went through this approach in considerable detail before deciding on the approach in the current design draft. Personally I think the current design draft is simpler to understand and to use. But we'll see.

I think contracts will be much more complicated if the focus is on the functionality in a language without operator overloading. There can be no types in go that implement < but not >.

For instance, once you require that a type must have + and - you limit the options to numeric types. I think it is more intuitive to write and read a contract that says "type T is a number" than writing "type T supports addition and subtraction".

Is this something that breaks BC, and must therefore be decided on before Go 2.0 ? If not, I'd personally prefer to first see how generics work out in practice, and only afterwards see if/what/how existing functionality like proposed here should be altered.

In my (highly uninformed) gut feeling, I think it's exactly the other way around: I believe contracts that enumerate type names could be sufficient, and contracts that list method names are redundant (due to the fact that interfaces already exist).

I could even imagine a more minimalistic approach: Just define a number of predefined contracts of meaningful subsets of predefined types, as they occur in the language specification (like Integer, FloatingPoint, Number, Assignable, Comparable, Ordered, Slice), and see how far we get with them. Maybe that's already far enough...

If you used interfaces in place of type names in contracts than multi-type contracts can get kind of awkward. For example, imagine that you want to write a contract for a Get() method. In the current draft, it's just

contract Get(T, K, V) {
  T Get(K) V
}

This clearly states exactly how all three types are involved in this. If you had to use interfaces, though, you'd have to do something like this:

type Getter(type K, V) interface {
  Get(K) V
}

contract Get(T, K, V) {
  T Getter(K, V)
}

That's pretty repetitive. And you can make it even more so by adding a constraint on one of those secondaries, like requiring K to match contracts.Numeric:

type Getter(type K, V contracts.Numeric(K)) interface {
  Get(K) V
}

contract Get(T, K, V) {
  T Getter(K, V)
}

or

type Getter(type K, V) interface {
  Get(K) V
}

contract Get(T, K, V) {
  contracts.Numeric(K)
  T Getter(K, V)
}

I should have been clearer: My suggestion is to have a list of predefined contracts, and not provide any means to define your own at all.

@bserdar

I think contracts will be much more complicated if the focus is on the functionality in a language without operator overloading. There can be no types in go that implement < but not >.

I think OP talks about different scenario. Let's assume we have some binary tree map type. For this type, keys should be ordered. With current approach to contracts, only predefined types support comparison operations directly. Other types should invent their own machinery to support ordering - and we're left with two distinct "contracts". But if we have standard contract like this

type Order int

const (
    OrderLess Order = -1
    OrderEqual Order = 0
    OrderGreater Order = 1
)

contract Ordered(L, R) {
    func Compare(L, R) Order
}

and have built-in types support it (where necessary), we may define our tree map as

type SomeTreeMap(type K Ordered(K, K), type V) {
    // ...
}

and have support for any type which wants to be map key

@ianlancetaylor Kind of argument for such "wrapper" contracts. Sorry if I reiterated unknowingly on something already discussed.

Going further, I'd say that contracts could in fact look like interfaces, with lists of available methods instead of "allowed expressions". The latter approach is what C++20 land will have with concepts, and it's IMO a losing game. You don't get precise requirement, only some vague requirement "this expression must compile" - which can often be achieved in multiple ways, often unintended.

If we go even further, we may go to conclusion that such contracts which are described as sets of functions are very similar to interfaces - except interfaces don't need to know their static type. So maybe it's possible to extend interfaces with "sized" methods and have single language entity cover both static and dynamic polymorphism. The closest approach is Rust traits.

@DeedleFake I encourage you to move this beyond a suggestion to actually write down the complete list of methods that would be required. Otherwise this is difficult to evaluate fairly.

@DeedleFake sorry for the nudge, but is this still relevant with adjusted generics we have now?

@DmitriyMV Sorry for interfering, though I'm interested in this topic too. AFAIK Go generics still have type lists and no way to make both builtin and user-defined types support same operations like arithmetics, hash computation etc.

This proposal is clearly outdated. There are ideas that are still relevant, but they would have to be completely rethought with the accepted generics approach that uses interface types rather than contracts. I'm going to close this issue but feel free to open a new one that is reworked for the present day. Thanks.