go/types, cmd/compile/internal/types2: type inference limitation leads to incorrect result for directed channel type constraint

[leaxoy]

Proposal Details

Think such code:
can be found here: https://go.dev/play/p/qNBK9KjxqrW

func Chan[E any, C ~<-chan E](c C) {}

func x() {
    c := make(chan int)
    Chan(c)
}

then Chan(c) produce chan int does not satisfy ~<-chan int (chan int missing in ~<-chan int)

In my opinion, this is a flaw in generic design that should be supported

[seankhliao]

I think this is just a type inference issue https://go.dev/play/p/YASG8TZx0Lc

cc @griesemer

[findleyr]

Indeed, I think we should be able to infer <-chan int for C when unifying ~<-chan E with chan int. As we've seen many times, encoding these types of assignability rules in the unification algorithm is tricky. But on first glance this may not be too bad.

[griesemer]

Let's consider the simpler example (no ~) with the same issue:

func f[C <-chan E, E any](C) {}

func _() {
    var c chan int
    f(c)
}

Per (internal) discussion: @findleyr points out that the code gives rise to three type equations:

1. C ≡A chan int (i.e., C and chan int match per assignability rules)
2. C ≡C <-chan E (C must satisfy constraint <-chan E)
3. E ≡C any

and that there is exactly one solution: C ➞ <-chan int and E ➞ int. With this solution, the code will work.

The implementation solves these equations using unification. When solving equation 1, unification infers C ➞ chan int. When solving equation 2, (inexact) unification infers E ➞ int. (For equation 3 there's nothing left to do.)
Because the implementation unifies one equation at a time and always infers (at most) one type (so chan int for C) rather than a set of possible types (like {chan int, <-chan int, chan<- int} for C) inference produces the wrong result after which instantiation fails, leading to the reported error.

Thus, this is an implementation limitation at the moment. It's unlikely that we'll be able to address this in the near future, as this is notoriously difficult and this is not a high-priority issue.

In this case it may be possible to just use the following work-around and write the code as follows:

func f[E any](<-chan E) {}

func _() {
    var c chan int
    f(c)
}

Leaving issue open for future reference/consideration.