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 <javascript:>> > 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) > > The most surprising result of this is that for a type that implements an > > interface with exclusively value receivers, you can pass either a > pointer or > > a value of that type as a function parameter for the interface. Since > all > > the methods have value receivers, then it's as if you passed a value to > the > > method, but without doing some casting I'm not sure if it is actually > passed > > into the method as a value or a pointer. > > https://golang.org/ref/spec#Method_sets > Thank you, this makes things much more clear. > 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? -MacRae -- 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.
