On Thu, Aug 31, 2017 at 2:05 PM, <macrae.lin...@gmail.com> wrote: > > On Thursday, August 31, 2017 at 12:45:25 PM UTC-7, Ian Lance Taylor wrote: >> >> On Thu, Aug 31, 2017 at 11:50 AM, <macrae...@gmail.com> wrote: >> >> > 1. method/function parameters are not coerced by the compiler. If a >> > parameter calls for a pointer, it must be a pointer at the call site. >> > 2. method receivers *are* coerced by the compiler. Regardless of the >> > pointerness/valueness (what is the right adjective here?) of a receiver, >> > the >> > compiler will turn the call into the correct one for the method. >> >> >> Your point 2 is not precisely accurate. In the specific case of >> x.M(), if M takes a pointer receiver, then the compiler will modify >> the expression to (&x).M(). This appears in the language spec at >> https://golang.org/ref/spec#Calls ("If x is addressable and &x's >> method set contains m, x.m() is shorthand for (&x).m()"). > > > Is the reverse not accurate? Given `val x *T` and x.M() where M takes a > value receiver, then the compiler will modify the expression to (*x).M()? Or > is there a deeper rule for turning pointers into values on demand? (It's not > allowed to pass a pointer into a function argument that requires a value, > though)
If M is a value method for T, then M is in the method set for both T and *T. So x.M() is not compiled as (*x).M() (though it has the same effect). x.M() is called simply on x, since M is in x's method set. >> > I'd love to understand some of the reasoning behind these seemingly >> > conflicting rules. I'm a little puzzled as to why receivers are treated >> > differently from parameters, and much more interested in why >> > implementing a >> > pointer receiver method forces an interface implementation to be a >> > pointer. >> >> I'm sure I'm too close to the language, but I don't see any conflict >> in these rules. >> >> Receivers are treated differently because we found that it was too >> annoying to force everyone to write (&x).M() all the time. >> >> The method set of the pointer type is always a superset of the method >> set of the value type, because it's trivial to dereference the pointer >> to get a value. It is not always possible to take the address of a >> value--some values have no address, such as a value returned by a >> function call. > > > This makes it sound like it is true that the compiler automatically > dereferences pointer receivers when calling value methods, why would that > not be the case for function parameters, then? A value method is in the method set of the pointer type. The pointer method is implemented by dereferencing the pointer and calling the value method. So, yes, in a sense you are correct that the compiler automatically dereferences pointer receivers when calling value methods, but that's not really the way the language looks at it. The language simply says that value methods are in the method set of the pointer type. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
