Thanks for reporting. Can you check if this is the same issue as #61903, which was recently resolved at tip, or not the same issue?

Hi,

I just tried with gotip and I still get an error though the formatting is slightly different (better):

$ gotip test ./match
# github.com/mokiat/gotest/match_test [github.com/mokiat/gotest/match.test]
match/eventually_test.go:46:16: cannot use Eventually(Produces(Eq("hello"))) (value of type match.Matcher[<-chan string]) as match.Matcher[chan string] value in argument to Assert: match.Matcher[<-chan string] does not implement match.Matcher[chan string] (wrong type for method Match)
                have Match(<-chan string) error
                want Match(chan string) error
FAIL    github.com/mokiat/gotest/match [build failed]
FAIL

$ gotip version
go version devel go1.22-a9859a7 Fri Aug 18 23:45:44 2023 +0000 darwin/amd64

To be honest, I am not sure which behavior is correct. In general Go does implicit casting from chan to <-chan or to chan<- and version Go 1.20 appeared to do the same with generic functions as well. Go 1.21 appears more strict and does not allow that now.

I have managed to simplify it to the following program:

package main

type Matcher[T any] func(T) bool

func Produces[T comparable](expected T) Matcher[<-chan T] {
	return func(ch <-chan T) bool {
		value := <-ch
		return value == expected
	}
}

func Assert[T any](a T, b Matcher[T]) {
	if !b(a) {
		panic("assertion failed!")
	}
}

func main() {
	ch := make(chan string, 1)
	ch <- "hello"
	Assert(ch, Produces("hello"))
}

This runs with Go 1.20 and does not compile with gotip or Go 1.21.

CC @golang/compiler.

This is a compiler bug somewhere, because there is an order dependency in type inference. This program, which swaps the order of the arguments to Assert, does compile:

package main

type Matcher[T any] func(T) bool

func Produces[T comparable](expected T) Matcher[<-chan T] {
	return func(ch <-chan T) bool {
		value := <-ch
		return value == expected
	}
}

func Assert[T any](b Matcher[T], a T) {
	if !b(a) {
		panic("assertion failed!")
	}
}

func main() {
	ch := make(chan string, 1)
	ch <- "hello"
	Assert(Produces("hello"), ch)
}

Just swapping the argument order should not affect type inference, but for channel direction it apparently does.

CC @griesemer

Simpler reproducer:

package p

func f[T any](T, T) {}

func _() {
	var a chan string
	var b <-chan string
	f(a, b)   // ERROR cannot use b (variable of type <-chan string) as chan string value in argument to f
	f(b, a)   // but this is ok
}

Definitely an inference/unification bug.

[Edit] This issue appears with both 1.20 and 1.21 so is a "pre-existing" error and slightly different from what was reported earlier. In any case, both of these should work.

The following simplified reproducer works with Go 1.20, but not with Go 1.21.

package p

type F[T any] func(T) bool

func g[T any](T) F[<-chan T] { return nil }

func f1[T any](T, F[T]) {}
func f2[T any](F[T], T) {}

func _() {
	var ch chan string
	f1(ch, g(""))
	f2(g(""), ch)
}

Change https://go.dev/cl/521500 mentions this issue: go/types, types2: remove order dependency in inference involving channels

@gopherbot please consider this for backport to 1.21, this is partly a regression and partly a pre-existing bug.

Backport issue(s) opened: #62205 (for 1.21).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.