go/types: infer generic type when it can be inferred without ambiguity

[h9jiang]

func dummyGeneric[E any](input, input2 E) E {
	return input
}

func dummyString(input, input2 string) string {
	return input
}

func _() {
	x := dummyGeneric("") // missing input 2
	y := dummyString("") // missing input 2

	x = "" // type of x is invalid
	y = "" // type of y is string
}

In the code snippet above, both the function call miss one input parameter. The type checker successfully figured out the type of y is string because it is not a generic function. However, the type checker did not successfully figured out the type of x is string.

When developing gopls, we encounter a lot of cases where the go source file is broken especially when the user is typing. A good use case is auto-completion in a generic function call

var x []string
slices.ContainsFunc(x, ${cursor})

In snippet above, the cursor is in the position of the second input parameter. It is clear that the user want to type func(s string) bool {}. But because we can not infer the generic type, we can not offer such auto-completion.

This is a FR to ask if type checker could infer the generic type if the context provide an un-ambiguous resolution. The type checker should keep the generic type invalid if the context is confusing

func foo[E any](input1, input2, input3 E) {}

func _() {
    foo("", "", ${type}) // the type is string
    foo("", 1, ${type}) // the type is invalid
}

We could try to match the argument to the signature by it's order. But I'm proposing the matching mechanism simply because it is the simplest and it matches the most with the human behavior. (as we tend to write input parameter from left to right.)

Signature (arg0, arg1, arg2, arg3 ....)
           /       /      /
Call (input0, input1, input2 ...)

Signature (arg0, arg1, arg2, arg3 ....)
           /       /      /
Call (input0, ${miss}, input2 ...)

cc @adonovan @mrkfrmn

[gabyhelp]

Related Issues

• spec: infer type arguments from assignments of generic functions (reverse type inference) #59338 (closed)
• go/types, types2: type inference fails when a prefix of type arguments is provided #44799 (closed)
• proposal: spec: infer parameter type from arguments in call to result function #64197
• proposal: spec: partial type inference from the left when only some type params can be inferred #74957 (closed)
• proposal: spec: infer function type parameters from generic interface arguments if necessary #52397 (closed)
• go/types: need best effort generic func instantiation #51803 (closed)
• go/types, types2: record instantiated type when fully instantiated function call is missing arguments #52503
• proposal: spec: avoid repeating concrete type parameters when generic arguments are passed to generic functions #53138 (closed)
• go/types, types2: explore "interleaved" type inference by combining function argument type inference with constraint type inference #51139 (closed)
• proposal: spec: Allow interfaces to be inferrable generic types #69822 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mwriter]

@h9jiang

There are also many examples accumulated here
#73527
It seems to me that Ian's comment there clearly describes the situation.

[prattmic]

cc @griesemer @findleyr

[griesemer]

Given a function

func f[P any](x, y P) P {
	return x
}

var z = f("foo") // invalid call: f is missing an argument

that is called with only one argument, say f("foo"), you are saying that the type checker should infer P to be string and then use that information to determine the type of z is string even though the call to f is invalid (because it's missing an argument).

While this would certainly be possible, currently, the type checker simply aborts when the number of arguments passed to a function is incorrect. There are assumptions (assertions) in the type inference code that assume we have all incoming arguments. Working around these assumptions would at the very least require a careful review of the type inference code to ensure things are working as expected, and perhaps adjust assumptions as needed. The relevant change may be small but the respective work is not. It's not obvious that this issue is important enough to warrant such a change.

More generally, using the suggested approach can lead to unexpected results. Consider the function f above: assuming we'd make this change, for the declaration

var z = f(0)

the type checker would infer that f was in fact f[int] and give z the type int. And of course report an error because the code is missing the 2nd argument for f.

On the other hand, if the code was complete

var z = f(0, 1.0)

now inference would conclude that f was in fact f[float64] and give z the type float64.

Is that really what gopls wants? At least in cases like this, switching from int to float64 may cause all kinds of follow-on errors to first appear and than disappear while typing. (Admittedly a bit a rare case.)

Putting on backlog for now. It would be good to have some strong evidence that the suggested behavior significantly improves gopls behavior; for instance by providing more examples that make the point.