I was just curious to see, if this was implemented (if it's possible to implement), how much of what's described in the contracts draft could we reasonably be able to do on top?

As an experiment I have attempted to rewrite parts of the contracts draft spec to make that assumption, and explore if we could write type parameterized types (as described in the contract draft proposal) without contracts.

• https://gist.github.com/smyrman/4f8c4201647b0bab4c196510a538e82c

The linked text is not actually a proposal, it's just an experiment.

Some personal assessments

Why not use interfaces instead of contracts?

It seams we can, just not all of the time. There are already two ways of defining contracts, so maybe one could use interfaces + something else...

(...) It is unclear how to represent operators using interface methods.

This seam to be solvable (for the most part) with the introduction of type parameterized interface default methods in a combination with applying type parameterization to the interface definition; interfaces are also types, so why not.

There is however at least one noticeable exception that I couldn't solve with interfaces alone: there isn't an obvious way (for me) to describe that a type must be viable for use as a map key in a type declaration. In the linked experiment I introduced something called kinds to work-around this, which is not to far from @pcostanza's suggestion of how contracts could work: #33410 (comment):

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.

Kinds and interfaces with default methods have however a lot of overlapping use-cases that an actual proposal should iron out. Perhaps one should make way for the other, or perhaps they could be altered to behave as similar as possible.

Mutually referencing type parameters

It appears possible (maybe) to do this with a special variant of type parameterized interfaces that in the experiment is called "self-referencing interfaces". It appeared possible (although more complex to understand) with "normal" type parameterized interfaces as well. A question I cannot answer, is how easy it would be for the compiler to understand.

Either way, the contract based code appear more clear to me. This is defiantly one of the places where contracts appear to shine.

Accept a combination of built-in types and custom-types with relevant methods

This appears one of the main strengths of the interface default methods, and doesn't appear to be possible with use of contracts. This is illustrated by sort example above or as part of the type parameterized interface example in the experiment.

This is a summary of the proposal as I understand it:

1. For each method m of an interface type T one may declare a default implementation (at most one).

2. The default implementation of a method m looks like any other method declaration except that a) the receiver type name T (which is the name of the interface) must be preceded with a $ as in $T, and b) the signature must match the existing method signature of m in the interface type.

3. Inside a default method, $T denotes the actual (concrete) type of the receiver.

4. A concrete (non-interface) type C implements such an interface T if C implements all methods which don't have a default implementation (more accurately: which don't have a default implementation that compiles for C).

(Then there is some fine print regarding embedding, etc. which doesn't seem relevant to understand the basic idea.)

First of all, I think this could be simplified: Instead of requiring that method signatures must match (which is only extra work for a compiler, and requires that two signatures be kept in sync by a programmer), why not simply permit that concrete methods may be added to an interface type as we allow for other types? Then we don't need the special rules. We can just write:

type Interface interface{}

func (s $Interface) Len() int { return len(s) }
func (s $Interface) Less(i, j int) bool { return s[i] < s[j] }
func (s $Interface) Swap(i, j int) {s[i], s[j] = s[j], s[i] }

The default methods would be part of the method set, of course, and they could be implemented by concrete types as before. The signature is the same. (This doesn't change the proposal's capabilities.)

The problem with this specific example though is that for many types, the default implementation doesn't compile (as you mention yourself), because many type don't understand indexing (in this example). In that case you suggest one has to provide default implementations for the relevant methods. But the only way to find out about this in general is by compiling the default methods (over and over, for each type C) again (note that a default method may be hugely complicated). Worse, the default method doesn't compile, it's not obviously clear what's wrong (with the concrete type) because the error depends on some implementation detail. This is something we absolutely want to avoid (and we do avoid it in the current contracts design draft). From a client's perspective it also seems odd that sometimes one doesn't have to provide an implementation for a default method, and sometimes one does, entirely depending on the internals of the default method.

Implementation-wise, default methods may often have to be custom-generated for each concrete type because they are effectively generic methods.

In summary, I don't see why we would not rather provide parameterized types and constraints (contracts) instead of a more restricted approach such as this which nevertheless has all the same problems. For instance, with the current contracts design, we can write:

// The existing sort.Interface.
type Interface interface{
    Len() int
    Less(i, j int) bool
    Swap(i, j int)
}

// A sort.Interface default implementation for a type T.
type Default(type T Indexable) T

func (s Default(T)) Len() int { return len(s) }
func (s Default(T)) Less(i, j int) bool { return s[i] < s[j] }
func (s Default(T)) Swap(i, j int) {s[i], s[j] = s[j], s[i] }

where Indexable is a contract that says that T must be a type that understands indexing (and thus len).

Your understanding of the proposal is correct. The syntax is preliminary, but it is intended to work as you describe it.

Your suggestion for simplification by omitting the default method signatures in the interface declaration sounds good to me, if the proposal should continue developing.

On your criticism of accepted types being determined by implementation detail, you are of course also right. I think the proposal as it stands could work very well for small and short default implementation, but that obviously isn't something you could possibly guarantee. I hadn't fully realized the consequence of determining acceptable types based on implementation detail as the complexity of the default method grows. I also hadn't realized that this means backwards compatibility of a package could in principal be (more easily) broken with no change in the public interface, which sounds bad. Of course, the same is true today for functions accepting interface{} as it's up to implementation detail to determine what types are actually accepted. The only difference is that this happens runtime now, but will happen compile time with this proposal.

Moving on, to your example using contracts, do you mean that as an alternative to develop this proposal, or something that can be done in the draft contract design already today? Could you elaborate a bit more on how it would work? I want to point out that Indexable is not enough though, the Less function requires the < operator (while the others don't). It would be super cool if I could for a single implementation of sort.Sort pass in either a type that supports the < operator, say []int, or a type where I bring my own Less, say []MyStruct. Although not particular relevant in this example, the same goes for the other methods; it would be good to only implement what is absolutely necessary for each passed in type.

I think the desire of this proposal boils down to, for an incoming type:

• Allow both a built-in and a method-based implementation for an operation X.
• Allow writing a minimal amount of code to implement an interface.

Solution to example using the latest generics proposal as I understand it:

type Interface interface {
	Len() int
	Less(i, j int) bool
	Swap(i, j int)
}

type comparable interface {
	type int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64, string
}

type comparableSlice[T comparable] []T

func (s comparableSlice[T]) Len() int           { return len(s) }
func (s comparableSlice[T]) Less(i, j int) bool { return s[i] < s[j] }
func (s comparableSlice[T]) Swap(i, j int)      { s[i], s[j] = s[j], s[i] }

type comparableMap[T comparable] map[int]T

func (s comparableMap[T]) Len() int           { return len(s) }
func (s comparableMap[T]) Less(i, j int) bool { return s[i] < s[j] }
func (s comparableMap[T]) Swap(i, j int)      { s[i], s[j] = s[j], s[i] }

type Restraint[T comparable] interface {
	type Interface, comparableSlice[T], comparableMap[T]
}

Usage

a := []int{3, 2, 1}
sort.Sort(comparableSlice(a))

I guess the only improvement here, is if your could do just:

a := []int{3, 2, 1}
sort.Sort(a)

But maybe we actually can do this with the new type-list interfaces?

type Restraint[T comparable] interface {
	type Interface, comparableSlice[T], comparableMap[T]
}

func Sort[T comparable](data Restraint[T]) {

  /// no code changes.
}

This doesn't currently seam to work in the playground:

• https://go2goplay.golang.org/p/WEbvPoVL_ra

The variant not defining a Restraint type list, does indeed work:

• https://go2goplay.golang.org/p/zKS1FII7bJi

Thanks, but now that Go has generics, we aren't going to do this.