spec: typeparams: method calls do not implicitly dereference pointer-to-TypeParams

[mdempsky]

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

[griesemer]

I would agree with this assessment.

[gopherbot]

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

[bcmills]

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]

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]

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]

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.