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.

[zigo101]

It looks this pointer conversion rule for type parameters is more relaxed than ordinary types.
In the following code, the bar function fails to compile, but the foo function compiles okay.

package main

type Age int

func foo[T ~*Age](x T) *int {
	return (*int)(x) // okay
}

type AgePtr *Age

//func bar(x AgePtr) *int {
//	return (*int)(x) // error: cannot convert x (variable of type AgePtr) to type *int
//}

func main() {
	var x AgePtr
	var _ = foo[AgePtr](x)
}

[zigo101]

The following function also doesn't compile.

func mud[T AgePtr](x T) *int {
	return (*int)(x) // error
}

So it looks the conversion rule in spec is not very accurate (or the foo function should not compile):

if T or x's type V are type parameters, x can also be converted to type T if one of the following conditions applies:

• Both V and T are type parameters and a value of each type in V's type set can be converted to each type in T's type set.
• Only V is a type parameter and a value of each type in V's type set can be converted to T.
• Only T is a type parameter and x can be converted to each type in T's type set.

[griesemer]

Too late for 1.20.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.21.
That time is now, so a friendly reminder to look at it again.

[griesemer]

Too late for 1.21.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.22.
That time is now, so a friendly reminder to look at it again.

[griesemer]

Reconsider this also in light of #63940.
Too late for 1.22.

[gopherbot]

This issue is currently labeled as early-in-cycle for Go 1.23.
That time is now, so a friendly reminder to look at it again.

[griesemer]

See also #63940 which may impact this one way or another.