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

mdempsky opened this issue Jul 2, 2021 · 4 comments


Copy link

@mdempsky mdempsky commented Jul 2, 2021

This test program exercises whether implicit dereference of pointer-to-type-parameter is allowed in a method call:

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: (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
Copy link

@griesemer griesemer commented Jul 3, 2021

I would agree with this assessment.

Copy link

@gopherbot gopherbot commented Jul 3, 2021

Change 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
Trust: Robert Griesemer <>
Reviewed-by: Robert Findley <>
Copy link

@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:

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.

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:

@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
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants