Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go/types,cmd/compile/internal/types2: inconsistent handling of len on pointer-to-array type parameters #47991

mdempsky opened this issue Aug 26, 2021 · 1 comment


Copy link

@mdempsky mdempsky commented Aug 26, 2021

This package currently fails to typecheck in H:

package p

func F[Ptr interface{ ~*Elem }, Elem interface { [1]int }](p Ptr) int {
  return len(p) // ok: types2 allows implicit dereference here

func G[Ptr interface{ ~*Elem }, Elem interface { [1]int | [2]int }](p Ptr) int {
  return len(*p) // ok(?): types2 allows explicit dereference and length of Elem

func H[Ptr interface{ ~*Elem }, Elem interface { [1]int | [2]int }](p Ptr) int {
  return len(p) // FAIL(?): types2 says len(p) is not allowed

It's unclear to me the correct behavior here, but the current behavior at least seems inconsistent to me.

/cc @findleyr

@mdempsky mdempsky added this to the Go1.18 milestone Aug 26, 2021
Copy link

@griesemer griesemer commented Aug 26, 2021

The "problem" here is that in F the Elem type parameter does have a structural constraint and thus (in the implementation) an operational type which is an array, and then implicit dereferencing works. In H, the Elem type parameter does not have a structural constraint (because it's type set has two types), and therefore no operational type, and then implicit dereferencing doesn't work anymore. This is probably an inconsistency we should try to address.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants