One can trigger the same issue on Go 1.19 with array pointers and slices:

func baz[T []int | *[2]int](x []int) {
	y := T(x)
	fmt.Printf("%T\n", y)
}

Thanks for the report. We can also take strings into account.

So I am aware of 25 sequence conversion cases with type parameters that type check at tip:

func f00[S string, D string](s S)                               { _ = D(s) }
func f01[S string, D []rune](s S)                               { _ = D(s) }
func f02[S string, D []rune | string](s S)                      { _ = D(s) }
func f03[S [2]rune, D [2]rune](s S)                             { _ = D(s) }
func f04[S *[2]rune, D *[2]rune](s S)                           { _ = D(s) }
func f05[S []rune, D string](s S)                               { _ = D(s) }
func f06[S []rune, D [2]rune](s S)                              { _ = D(s) }
func f07[S []rune, D [2]rune | string](s S)                     { _ = D(s) }
func f08[S []rune, D *[2]rune](s S)                             { _ = D(s) }
func f09[S []rune, D *[2]rune | string](s S)                    { _ = D(s) }
func f10[S []rune, D *[2]rune | [2]rune](s S)                   { _ = D(s) }
func f11[S []rune, D *[2]rune | [2]rune | string](s S)          { _ = D(s) }
func f12[S []rune, D []rune](s S)                               { _ = D(s) }
func f13[S []rune, D []rune | string](s S)                      { _ = D(s) }
func f14[S []rune, D []rune | [2]rune](s S)                     { _ = D(s) }
func f15[S []rune, D []rune | [2]rune | string](s S)            { _ = D(s) }
func f16[S []rune, D []rune | *[2]rune](s S)                    { _ = D(s) }
func f17[S []rune, D []rune | *[2]rune | string](s S)           { _ = D(s) }
func f18[S []rune, D []rune | *[2]rune | [2]rune](s S)          { _ = D(s) }
func f19[S []rune, D []rune | *[2]rune | [2]rune | string](s S) { _ = D(s) }
func f20[S []rune | string, D string](s S)                      { _ = D(s) }
func f21[S []rune | string, D []rune](s S)                      { _ = D(s) }
func f22[S []rune | string, D []rune | string](s S)             { _ = D(s) }
func f23[S []rune | [2]rune, D [2]rune](s S)                    { _ = D(s) }
func f24[S []rune | *[2]rune, D *[2]rune](s S)                  { _ = D(s) }

Might still be missing something.

Some of the above like func f19[S []rune, D []rune | *[2]rune | [2]rune | string](s S) { _ = D(s) } do not seem well served by Convert, ChangeType or SliceToArrayPointer as they are today.

My main point is that representing something like

func f[S []rune, D ~[]rune | *[2]rune | [2]rune | ~string](s S) { d := D(s); _ = d }

is challenging with the current set of x/tools/go/ssa Instructions. The []rune to *[2]rune case requires a SliceToArrayPointer (which can panic). [2]rune is roughly a dereference of a SliceToArrayPointer. While []rune to string, is a Convert instruction (which cannot panic). We have to pick something to emit in ssa, and nothing at the moment seems to fit the bill.

A possible solution is to have a "MagicConvert" instruction that just handles all of these cases. MagicConvert could just be a relaxation of the current Convert instruction, or something new. Another possible solutions is use a type switch of the type of D. This seems to require TypeAssert to have a mode for looking at the underlying type instead of an exact match. #45380 is related.

A less important point is 'that is a lot of sequence conversion cases'. I found this slightly surprising.

I've considered a type switch approach, but I am worried that this will make analysis of generic functions more difficult for end users, as the SSA will be more removed from the source representation. The switch statement will introduce new phi nodes, and more (impossible) paths through the program, for example if the type switch is inside a loop.

I haven't yet come up with anything better than MagicConvert (GenericConvert?). It's probably also worth keeping ChangeType in mind.

I've considered a type switch approach, but I am worried that this will make analysis of generic functions more difficult for end users, as the SSA will be more removed from the source representation.

All fair points.

My gut reaction from issue is that maybe SliceToArrayPointer was added too hastily and we should try to aim for more fundamental instructions [and smaller code deltas?] in the future. If #45380 is accepted, the type switch approach is the smallest user interface change (delta would be 0). Kinda speculative, but that is a point in favor of the type switch.

I'm not really sure which approach will be better in the long term.

GenericConvert

This is a good name and maybe a decent way to approach scoping what the instruction would do.

It's probably also worth keeping ChangeType in mind.

+1. I don't think ChangeType should be touched. Tough maybe it is emitted in fewer places.

My gut reaction from issue is that maybe SliceToArrayPointer was added too hastily and we should try to aim for more fundamental instructions

In our defense, we didn't expect generics to be this generic :P And I think the instruction is still very useful in combination with instantiation, or with type sets where all types permit SliceToArrayPointer to be used. I don't think that our existing instructions are too specific, only that we may not have ones that are general enough for generic functions.

I don't think ChangeType should be touched. Tough maybe it is emitted in fewer places.

I wasn't thinking of changing it. My point was more that ChangeType is one more semantic that GenericConvert might have if we extend the type sets above, in addition to SliceToArrayPointer, SliceToArrayPointer + dereference, and Convert.

Change https://go.dev/cl/457335 mentions this issue: go/ssa: emit conversion by type switch

Change https://go.dev/cl/457436 mentions this issue: go/ssa: add GenericConvert instruction

My 2c: GenericConvert seems simpler, generates less code, and feels consistent with how other operations have been extended. E.g., append and copy on bytestring don't type switch to separately handle []byte and string.