When you write

// x, y has the same type
func Max(x, y Numeric) Numeric {

are you saying that x and y have the same dynamic type? Because interface types don't work that way. The language has no way to require that two different interface values have the same dynamic type. Are you also adding that requirement in some way? If so, how?

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

@ianlancetaylor

When you write

// x, y has the same type
func Max(x, y Numeric) Numeric {

are you saying that x and y have the same dynamic type? Because interface types don't work that way. The language has no way to require that two different interface values have the same dynamic type. Are you also adding that requirement in some way? If so, how?

contract Numeric(T) {
	T int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64
}

func Max(type T Numeric)(x , y T) T {
	...
}
Max(int)(x, y) 
// if type inference is possible, can be write 
Max(x, y)

Similar with Contracts

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

func Max(type T)(x, y T) T {
	...
}
// for short can be write
func Max(x, y T) T {
	...
}

No, interfaces and type parameters are very different.

When I write

func F(x, y interface{})

then x and y can have different dynamic types.

When I write

func F(type T)(x, y T)

then x and y must have exactly the same type.

Got it. I think contracts is very good, just syntax is complex.

// contracts - syntax like function，but body like struct
// func functionName (Parameters) 
contract Numeric(T1, T2) {
	T1 int, int32 // anotherContract(T1)
	T2 float32, float64
}

contract Numeric1(T1, T3) {
	T1 int, int32 // anotherContract(T1)
	T3 uint, uint32
}

type SomeType(type T1, T2 Numeric) map[T1]T2
func (a SomeType(T1, T2)) M() SomeType(T1, T2) 

func(type T1, T2 Numeric)(x T1, y T2)
func(type T1, T3 Numeric1)(x T1, y T3)

How about as a new type, seem more flexible.

type T1 contract {
	int, int32
}
type T2 contract {
	float32, float64
}
type T3 contract {
	uint, uint32
}

type SomeType(type T1, T2) map[T1]T2
func (a SomeType(type T1, T2)) M() SomeType(type T1, T2)
// short can be write
type SomeType map[T1]T2
func (a SomeType) M() SomeType

func(type T1, T2)(x T1, y T2)
func(type T1, T3)(x T1, y T3)
// short can be write
func(x T1, y T2)
func(x T1, y T3)

I like the idea that any primitive can be an interface.
Since Interfaces are set of methods, and int for example could implement arithmetic (+, -, *, /) , comparable (>, <, >=, <=, !=, ==), and basically, any thing that can perform/do operations implements something. Even empty struct implements something.
This would mean anything was an interface and would form as an "Interface-oriented",

So, the following could be possible, and for me I'm not sure about type parameter, but the interface type could just be fine:

type int interface {
	Arithmetic // interface to operators
	Comparable // interface to operators
	Stringer // interface to operators
	// etc..
}
...
type T interface {
	int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64
}

func Max(x, y T) T {
	...
}

The "etc." leaves out a lot when you start to think about slices, maps, channels, type conversions, untyped constants, slice expressions, index expressions, range loops.

@gocs If I'm not mistaken, what you say falls under the same pitfalls as the original proposal.

For instance, in the following code:

type T interface { int64, float64 }

func Max(x, y T) T {
    // ...
}

func main() {
    var i int64 = 9007199254740993
    var f float64 = math.MaxFloat64

    m := Max(i, f)
    a := Max(i, i)
    b := Max(f, f)
}

What are the types of m, a, and b? One might say that a is int64 and b is float64, but then what about m? One might try to say "then maybe all three are type T, although that means that in order to get back to int64 or float64, you would need a type conversion for trivial operations: strconv.FormatInt(int64(Max(5, 6)), 10) instead of the much more readable strconv.FormatInt(Max(5, 6), 10).

Hi @deanveloper,

What are the types of m, a, and b?

The types of m, a, and b is T because that is what the function returns.

you would need a type conversion for trivial operations: strconv.FormatInt(int64(Max(5, 6)), 10)

If you would want to format string from int, the formal definition of func FormatInt(i int64, base int) string would be changed into type Num interface { int, int64, float64, ... }; func Format(n Num, base int) string and use something like strconv.Format(Max(5, 6), 10).

type T interface {
    // primitive type embeddings doesn't break compatibility because interfaces are implemented implicitly and already is.
    int // implements greater than operator and others implicitly
    int64 // implements greater than operator and others implicitly
    float64 // implements greater than operator and others implicitly
}

func Max(a, b T) T {
    if a > b { // both variables are comparable because int, int64, and float64 are comparable
        return a
    }
    return b
}

i := Max(1, 1.1)
s := strconv.Format(i, 10)

I'm aware that there has to be a type between a struct and an interface, and it does not have to be a "Generics".

• structs is too static
• interface is too dynamic
• structs can't be in an interface
• interfaces can't have methods

IMO, this is my check list for a contract-like proposal:

• contracts should be able to embed structs, interfaces, and another contract
• contracts should be orthographic like structs and interfaces
• contracts should be just a statement and generated on compile-time
• contracts should precede all the types including method receiver

also, only thing holding me back is func (a A) B(type C, D)(e E, f F)(g G, h H) { return } might be too much. maybe put the type parameter out of the function declaration from another proposal