The Updated Draft Design for Go 2 Contracts (go.googlesource.com)

What in the draft is unclear?

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

    Map(T, U type)(t []T, f func(T) U) []U

    Map(type T, U)(t []T, f func(T) U) []U

The terminology comes from a proposal for C++ which has been under discussion for a long time.

Why not? They certainly define contracts for the type - at least that's my non-native speaker understanding of the english word.

It might seem weird if one used a different programming language which used the term for a slightly different concept - but that doesn't mean Go's usage is bad.

The concept is similar to what concepts are in C++ and traits in Rust. And from those terms I actually find contract to be the most understandable for people who are new to these things.

They want to avoid the term "generics" or "traits", same as how they avoided the word "exception" when they implemented "panic". golang likes to reinvent the wheel and call it something else just for the sake of it.