cmd/compile: type inference could be less strict when there are interface arguments

[rogpeppe]

The following program fails:

func Equal(type T comparable)(x, y T) bool {
	return x == y
} 

func main() {
	var x interface{} = 5
	var y = 5

	fmt.Println(Equal(x, y))
}

The error is:

prog.go2:15:23: type int of y does not match inferred type interface{} for T

Although it's true that the types don't match exactly, it seems to me that it might be nice
to allow the type argument to unify to interface{} in the same way that we allow
a concrete type to be passed to an interface type.

[mmaedel]

hi @rogpeppe
i am with you and if with a 'comparable', it would be nice to even have it in basic types...

this:

func main() {
var x interface{} = 5
var y = 6.1

fmt.Println(Equal(x, interface{}(y)))

}

should also work for:

func main() {
var x = 5
var y = 6.1

fmt.Println(Equal(x, y))

}

[ianlancetaylor]

I am very concerned about avoiding any possible confusion in which type inference does not act as people expect. This is based on the complexity of the C++ equivalent to type inference, which observably confuses people. I would rather say that if there is any confusion, the programmer must explicitly state the desired type.

[bcmills]

I too would like to see better type inference here, but I think this is the sort of refinement that can (and should!) wait until after the initial implementation and release of generics, so that we can gather empirical evidence to weigh the cost (of more difficulty reasoning about inference) against the benefit (of avoiding the verbosity and distraction of “obvious” annotations).

[griesemer]

Updated playground link (new syntax).

The idea here in its simple-most form is that if multiple function arguments have the same type parameter type, the "most general" type parameter type should be chosen.

In this example, x and y have the same type parameter type T and the argument types are interface{} and int. Since int values can be assigned to interface{} variables, T should be inferred to be interface{}.

It gets complicated very quickly (e.g., argument types are different interface types that build a type hierarchy, or channel types with different directions, etc.).

In any case, this needs a concrete proposal describing what's in scope.

[griesemer]

If we say that a non-interface type V unifies with an interface type T if V implements T under unification, this code will work. (If V is a type parameter that doesn't have a type inferred for it yet, then we infer T for V, of course.)