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.
…ls on ptr to type parameter receivers
Simplify the implementation of asInterface while at it.
Trust: Robert Griesemer <firstname.lastname@example.org>
Reviewed-by: Robert Findley <email@example.com>
I think an implicit dereference of *Tshould 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.
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.
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.