cmd/go2go: improve error messages when types don't satisfy constraints

[urandom]

The following program fails to compile: https://go2goplay.golang.org/p/-2Qmhtax9VX
The following error is observed:
prog.go2:238:9: *mapIt(string, int, reverse(string, ReverseIterator(string))) does not satisfy Iterator(T) (missing method Next)

Note that on line 224, the same parametric type is being instantiated, and used in 228 without a problem. Also note line 238, invoking the method the type checker complains about.

[ianlancetaylor]

If I'm reading the code correctly, there should be an error here. But it would be nice if the error were better.

The line is

	err := ForEach(m2, func(i string) {

Here m2 has type mapIt[string, int, reverse[string, ReverseIterator[string]]].

The ForEach function is

func ForEach[T any, I Iterator[T]](it I, consumer func(T)) error {

So I must be the type of m2, shown above. And T must be string. So we require that the type of m2 must satisfy the constraint Iterator[string].

We have

type Iterator[T any] interface {
	Next() (T, bool)
}

So the type of m2 must have a method Next() (string, bool). The mapIt Next method is

func (i *mapIt[T, U, I]) Next() (U, bool) {

so in this case the type of the Next method is actually Next() (int, bool). But we need Next() (string, bool).

So I believe the type checker is correct to report an error. But the error shouldn't be missing method Next. It should be something more like "method Next with type Next() (int, bool) does not satisfy constraint which requires Next() (string, bool).

That would be a start, anyhow. It's still pretty hard to understand what is going on here. It would be good to see if there is something we can do to make it clearer.

[urandom]

Yes, that is indeed the issue, though I also didn't realize it at first. I've seen the type checker be able to tell the difference between methods with different instantiated parameters, so it's definitely able to report the error correctly in such cases

[gopherbot]

Change https://golang.org/cl/251717 mentions this issue: [dev.go2go] go/types: improve error when a type argument doesn't satisfy constraint

[griesemer]

The new error message is now:

tmp.go2:245:9: *mapIt[string, int, reverse[string, ReverseIterator[string]]] does not satisfy Iterator[T]: wrong method signature
                found func (*mapIt[T, U, I]).Next() (U, bool)
                want  func (Iterator[T any]).Next() (string, bool)

This can be improved further (the T, U, I parameters should be substituted), but this is already better than what we had.

Leaving this issue open for now for future improvements.

@urandom, please simplify test cases when reporting an issue; it makes it significantly easier to figure out what's going on.

[urandom]

Perhaps the following example illustrates a similar message problem:
https://go2goplay.golang.org/p/O1Un2Vm9Dh0

The compiler outputs:
prog.go2:33:30: interface contains type constraints (T)

I initially through that parametric interfaces weren't allowed in type assertion expressions.

As pointed out in golang-nuts however, it appears that the problem is the fact that the interface has a type list. Perhaps the message should say so instead.

[griesemer]

@urandom Well, a type list is a type constraint. But agreed, this should probably say "type list" instead (or whatever we use as the official terminology once we have a spec). Not urgent.

[griesemer]

The Go 1.18 error message is now:

./prog.go:239:16: *mapIt[string, int, reverse[string, ReverseIterator[string]]] does not implement Iterator[string] (wrong type for Next method)
		have Next() (int, bool)
		want Next() (string, bool)

which seems pretty decent. Closing.