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)
}

CC @griesemer

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

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.

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.

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

Underlying types are identical, but both are Named.

@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.

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