I found some more discussion that is relevant to this proposal.

The Go Wiki the Rationals page has a section on pointer receivers that provides a similar justification for why pointer receivers are not supported:

Suppose you have:

type T blah
type P *T

func (t *T) String() string { ... }
func (p P) String() string { ... }

var p P

Then the meaning of the expression (*p).String() is ambiguous, because it can refer to both (*T).String and P.String.

Ref: https://github.com/golang/go/wiki/Rationales/c2d2e158f292621916801012908bc02819421be3#why-method-receivers-base-type-cannot-be-pointer-or-interface

I think this justification has the same problem as the similar but different justification that I included in this issues first comment/description. (*p) is always of type T, not *T or P.

This is demonstrated with the below code. Because (*p) is always of type T, the Go spec is clear that the String method called is T.String().

type T int
type P *T

var t T = 0
var p P = &t

fmt.Printf("%T\n", p)
fmt.Printf("%T\n", *p)

main.P
main.T

Ref: https://play.golang.org/p/G6TIyJQVB2g

Other variations are also deterministic, such as &p which is always of type *P, which according to the Go spec is unambiguous that it calls P.String() since the method set of pointer type *P is the set of all methods declared with receiver *P or P:

fmt.Printf("%T\n", &p)

*main.P

Ref: https://play.golang.org/p/I8eaEWAOK7C

I agree that it is possible to define rules to make this work without ambiguity. But I think the result will be subtle and difficult to understand. It will require a clear grasp of the exact type of different expressions, and a clear understanding of the exact rules.

Given that, and the fact that we have lived with the current rules for some time, what is the compelling reason for making this change? It seems possible to write the initial example using a struct with a pointer field and adding methods to the struct. This may require a bit more code in some places, but the advantage of that code is that it makes clear what is happening, and does not require the reader to understand the types and the rules. Having different marshaling for a type and a pointer to a type is confusing; introducing a different type to clarify matters seems like a good idea even if it requires writing a little more code.

But I think the result will be subtle and difficult to understand. It will require a clear grasp of the exact type of different expressions, and a clear understanding of the exact rules.

The counterintuitive quality of pointer types for me is that you can dereference a pointer type P and get a non-pointer type I. Even though it makes sense, it is counterintuitive because dereferences usually result in the same type but with less asterisks, and since pointers to types inherit method sets, usually method sets of a dereferenced value are only a subset for a single dereference.

I don't think this proposal defines new rules that are counterintuitive, because it is valid to create a pointer type P today, and valid to dereference it and get I. I mean to say that the counterintuitive rule exists today.

I do think this proposal will create new instances where this counterintuitive quality shows up, which could be a problem. There are two instances I can think of:

1. There is no function today where the receiver when dereferenced can change from P to I. The receiver can only change from *I to I. This could mean dereferencing the receiver, then calling functions on it would be confusing. A reader could see the function calls assuming they are calling P.Func, when they are calling I.Func. The fact they call I.Func is correct, just surprising.

2. This counterintuitive quality can already show up for any other parameter of a method. Dereferencing a parameter of type P will become I. So it's possible to misunderstand what is happening inside a function already. However, the chance of calling a wrong function is nil since today P has no functions.

Both of these situations seem like they affect readability too greatly.

what is the compelling reason for making this change? It seems possible to write the initial example using a struct with a pointer field and adding methods to the struct.

The compelling reason was to be able to write parsers that map directly onto types defined in other forms, such as XDR, where types can be pointer types. Using a struct as you say is definitely valid alternative.

The specific library this proposal would benefit supports marshaling/unmarshaling both by using reflection and by using generated code. The reflection marshaler can easily support the pointer type because it needs no functions on the type, it only needs to be able to inspect the type, and its fields in the case of a struct or its underlying type. The code generator on the other hand needs to add functions to the pointer type. My dilemma is that while introducing a struct with fields in place of the pointer type will work in the code generated case, it will break the reflection based marshaler because the reflection based marshaler can no longer identify that the type is a pointer type, since the type is now a struct that wraps a pointer. I realize this isn't an insurmountable problem, I'm just detailing it here for the full picture.

@ianlancetaylor Thanks. I agree with your comments. 👍🏻

Based on the discussion above, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.