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: method calls do not implicitly dereference pointer-to-TypeParams #47031

mdempsky opened this issue Jul 2, 2021 · 6 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 the NeedsDecision label Jul 2, 2021
@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:

Copy link

@griesemer griesemer commented Oct 28, 2021

Decision: For Go 1.18 at least we are not going to permit implicit dereferencing of pointer-to-type-parameter types.
Leaving open so we can be sure this is incorporated into the spec as such.

@griesemer griesemer added Documentation and removed NeedsDecision labels Oct 28, 2021
@griesemer griesemer changed the title spec: typeparams: clarify whether method calls are allowed to implicitly dereference pointer-to-TypeParams spec: typeparams: method calls do not implicitly dereference pointer-to-TypeParams Oct 28, 2021
Copy link

@griesemer griesemer commented Feb 11, 2022

Since the underlying types of type parameters are their constraint interfaces, the rules here fall out from what we already have (at least for now): pointers to interfaces don't have any methods. It seems that there's no need to explicitly document this is in the spec. Closing.

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

No branches or pull requests

4 participants