When programmers complain about the lack of generics in Go, a common mitigation
proposed is to use a interface. In many cases, it's possible to find an
operation common to all the types to be supported; in the worst case, an empty
interface can be used.<p>This doesn't satisfy many Go programmers, so a proposal for generic types has
been made, containing the contract keyword:<p><pre><code> contract Ordinal(t T) {
t < t
}
</code></pre>
So a contract looks basically like an interface, which doesn't require a type
to implement a certain method, but to support the use of certain operations on
it.<p>When I think of operations and types that apply to them in Go, the following
categories come to my mind:<p>1. Equality, expressed by == and !=, which is supported by most Go expressions.
2. +, which adds up numbers and concatenates strings.
3. Other operations for arithmetics and comparison: -, *, /, %, <, >, <=, >=.
4. Accessors and qualifiers: . and []<p>Complaints about the lack of generics in Go are often heard from programmers
that want to implement numeric libraries. They basically want a type, which
support the operations of the first three categories, which are basically the
numeric types: integer, floating point and complex numbers.<p>So an abstract "numeric" or "number" type could eliminate a lot of the use
cases for contracts. Is this an option being considered? Or isn't there just
any benefit over using the double type for numeric computations?