On Mon, Jul 29, 2019 at 7:05 AM Ilia Choly <ilia.ch...@gmail.com> wrote: > > 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?
The motivation is to avoid requiring contracts to specify whether a method is a pointer method or a value method, just as we do not require interface types to specify whether a method is a pointer method or a value method. It does make it possible to write certain kinds of bugs, but it's not clear how much that arises in practice. That said, it's likely that we will have to modify contracts to require a pointer method in some cases, in order to separate defining a variable of some type with invoking pointer methods on that variable, so I would not be surprised if this aspect of the design draft is changed. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWgzkqS4GHH%2BbcQd6KNGJrRd1v2d0D2GU5LsomJF0SL%3Dw%40mail.gmail.com.
