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

spec: typeparams: clarify whether method calls are allowed to implicitly dereference pointer-to-TypeParams #47031

Open
mdempsky opened this issue Jul 2, 2021 · 4 comments
Assignees
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jul 2, 2021

This test program exercises whether implicit dereference of pointer-to-type-parameter is allowed in a method call: https://go2goplay.golang.org/p/0C-j_EutS4c

go/types and cmd/compile/internal/types2 both accept it, but then go2go, cmd/compile -G=3, and cmd/compile unified all produce a "calling method M with receiver p (type **MyMer) requires explicit dereference" error during code generation.

A similar issue affects instantiating type parameters with interface types: https://go2goplay.golang.org/p/-vWtl3FTslw. (Here go2go and unified both report "p.M undefined (type *Mer is pointer to interface, not interface)"; -G=3 hits an assertion failure.)

What's the expected behavior here? Should go/types reject these cases as invalid, or do the compilers need to insert the implicit dereference? I don't see anything mentioned about this in the proposal.

My intuition is these are invalid, and go/types should reject them. Type parameter types act like interface types, and we don't allow implicit dereference of pointer-to-interface-type values in method calls.

/cc @griesemer @ianlancetaylor @findleyr @bcmills

@mdempsky mdempsky added this to the Go1.18 milestone Jul 2, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Jul 3, 2021

I would agree with this assessment.

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 3, 2021

Change https://golang.org/cl/332609 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: don't permit method calls on ptr to type parameter receivers

gopherbot pushed a commit that referenced this issue Jul 7, 2021
…ls on ptr to type parameter receivers

Simplify the implementation of asInterface while at it.

For #47031.

Change-Id: Ie7d4fbbab898d961ed3c0b7772ba9604641be13f
Reviewed-on: https://go-review.googlesource.com/c/go/+/332609
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@bcmills
Copy link
Member

@bcmills bcmills commented Jul 8, 2021

For this example, note that since you can instantiate T with Mer itself, it is possible for T to be an interface type in this case: https://go2goplay.golang.org/p/KprMnRIinWV

I think an implicit dereference of *T should be allowed if T is constrained to only concrete types (no pointer or interface types), and an implicit dereference of T itself should be allowed if T is constrained to only pointer types (no value or interface types). But those cases are probably rare enough that it's not a huge deal if we spuriously reject them too.

@mdempsky
Copy link
Member Author

@mdempsky mdempsky commented Jul 8, 2021

I'm similarly okay with allowing implicit dereference of pointer-to-TypeParam as long as the TypeParam is constrained to disallow instantiation as an interface type; but similarly skeptical that it's important enough to prioritize for Go 1.18.

This seems like something worth revisiting if/when we extend generics to better support pointer-receiver parameters: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-way-to-require-pointer-methods

@griesemer griesemer self-assigned this Jul 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants