When converting a non-pointer value to an interface, pointer methods cannot be used to satisfy the interface. Even though the compiler could add instructions to take the value's address, this is not allowed because it's error prone. Since pointer methods usually mutate the receiver, you don't want to be operating on a copy. https://play.golang.org/p/XDiki8_uHMs
When reading the contracts proposal, I'm confused by the seemingly contradictory decision to allow pointer methods. https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#methods In order to avoid worrying about the distinction between value methods and > pointer methods, in a generic function body all method calls will be > pointer method calls. If necessary, the function body will insert temporary > variables, not seen by the user, in order to get an addressable variable to > use to call the method ...This makes it easier to understand which types > satisfy a contract, and how a contract may be used. It has the drawback > that in some cases a pointer method that modifies the value to which the > receiver points may be called on a temporary variable that is discarded > after the method completes. It may be possible to add a vet warning for a > case where a generic function uses a temporary variable for a method call > and the function is instantiated with a type that has only a pointer > method, not a value method. The same example converted to use interfaces fails https://play.golang.org/p/FBbXQw7dKL6 What's the motivation for this design decision? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8bd8a205-77fa-4a82-bfdf-8a92e4d004e3%40googlegroups.com.
