I was bitten this week by not understanding how interfaces in method parameters interacted with pointers. After playing around I finally figured out these rules
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. 3. If *any* of the methods you implement an interface with have a pointer receiver, then only a pointer of that type will satisfy the interface. 4. If *none* of the methods you implement an interface with have a pointer receiver, then either a pointer or a value of that type will satisfy the interface. Please tell me if I have any of that wrong but I've got a gist to show for it so I think it's right. 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. 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. Thank you, -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.
