cmd/compile: adjustment needed for conversion rules for pointer conversions (?)

[keep94]

What version of Go are you using (go version)?

go1.18-16d6a5233a Tue Jan 25 00:39:08 2022 +0000. Using gotipplay.golang.org.

Does this issue reproduce with the latest release?

No.

What operating system and processor architecture are you using (go env)?

I am using gotipplay.golang.org.

What did you do?

func Sum[Slice ~[]int](aslice Slice) int {
    p := (*[]int)(&aslice) // compile error: cannot convert &slice (value of type *Slice) to type *[]int
    result := 0
    for _, y := range *p {
        result += y
    }
    return result
}

What did you expect to see?

I expect p to be a *[]int

What did you see instead?

A compile error. cannot convert &slice (value of type *Slice) to type *[]int.

[randall77]

I think this should work. It does in the non-generic equivalent.
I suspect this is an interaction with structural types?
@griesemer @findleyr

[mknyszek]

Based on @randall77's comment, tentatively marking as a release blocker.

Maybe this is go/types actually, I'm not sure. Feel free to update the title to better reflect where the issue lies.

[griesemer]

This is working as intended per the current rules and unrelated to structural types. Not a release blocker.

[griesemer]

We have special rules for generic conversions, but what we have here is not a generic conversion (at the top level). We convert a *Slice to a *[]int which is a pointer type conversion. The rule is:

ignoring struct tags (see below), x's type and T are pointer types that are not named types, and their pointer base types are not type parameters but have identical underlying types.

Here x's type is *Slice and T is *[]int. The pointer base types are Slice and []int, and Slice is a type parameter, so we can't convert. But even if we allowed a type parameter, this specific rule would fail because the underlying types (interface{ ~[]int } vs []int) don't match. We would need a new rule.

This case has come up before, and maybe we need a new rule for this case (resp. an adjustment of the new rules added for generic conversions.)

Leaving open for decision.

@ianlancetaylor

[ianlancetaylor]

I think we should probably permit this, but perhaps not for 1.18.