cmd/go2go: conversion using type lists

[benjaminjkraft]

Consider the following code (playground):

func Convert(type T interface{}, U interface{ type T })(t T) U {
	return U(t)
}

It does not compile, with the error:

prog.go2:4:11: cannot convert t (variable of type T) to U

It seems to me like this should compile: the design says

More precisely, the underlying type of the type argument must be identical to the underlying type of one of the types in the type list.

which I understand to mean the underlying type of U must be identical to the underlying type of T; the spec gives that as a sufficient condition to allow U(t).

[benjaminjkraft]

Relatedly, it looks like the following more specialized function gives the same error:

func ConvertToString(type T interface{ type string })(t T) string {
	return string(t)
}

[ianlancetaylor]

CC @griesemer

I think that strictly speaking the design draft says that this code should not compile. It's an interesting case, though.

[ianlancetaylor]

The reason I say that it maybe should not compile is that your argument hinges on the underlying type of T, which is a little murky.

[benjaminjkraft]

I think both design draft and spec refer to underlying types on both sides in the relevant contexts?

Not that I would be particularly sad if it didn't, as long as it's clear: this code didn't end up being very useful to me for other reasons.

[tdakkota]

First case is similar a bit to #39930 (comment).
operand.assignableTo function just fails to match two types.
It happens because there are not checks for underlying

• *types.TypeParam and *types.top

Second example fails here

go/src/go/types/operand.go

Line 269 in 6cf6bf1

if check.identical(Vu, Tu) && (!isNamed(V) || !isNamed(T)) {

Underlying types are identical, but both are Named.

[griesemer]

@tdakkota That may be the reason for this failure but not the reasoning as to why it shouldn't fail.

@ianlancetaylor has pointed at the culprit: The outcome hinges on what the underlying type of a type parameter is. One answer is that it is described by the type list in its constraint. Another one is that the underlying type of a type parameter is itself. Currently we implement the latter. The correct answer may be some variation of the former. This is under active investigation.

[griesemer]

The first example here is not valid code with Go 1.18. The second example (adjusted) works now as expected. Closing.