as I understand it (and I may be misunderstanding it), contracts are exactly like interfaces, except the type of parameters/return values is left to the implementation.

So an interface of "adder" would look like:

    type adder interface {
        Add(int) int
    }

and it would only be able to support adding an int to something, and returning an int. Doing this:

    func AddStrings(a adder, b string) string {
        return a.Add(b)
    }

will break

A contract for "adder" would look like:

    contract adder(T) {
        T Add (T) T
    }

You can then use this in a function by:

    func addTheThings(type T adder)(t1, t2 T) T {
        return t1.Add(t2)
    }

which can then use any type that has an Add method

    //can't extend native types, so we have to create an alias and extend that
    type Addstring string

    func (a Addstring)Add(b Addstring) Addstring {
        return a+b
    }

    func (a Banana)Add(b Banana) Banana {
        return Banana{a.Count + b.Count}
    }

then your "addTheThings" function can operate on strings (via the Addstring type) and Bananas, and anything else that fulfills the contract. So the original example:

    func AddStrings(a adder, b string) string {
        if as,ok := a.(Addstring); ok {
            return a.Add(b)
        }
        //raise an error here
    }

On a separate note, why is "contract" becoming a keyword instead of "type foo contract {}"? Making the common business concept of "contract" a keyword is likely to break backward compatibility for some code bases