This completely answers my question. On Monday, July 29, 2019 at 8:49:31 PM UTC-4, Steven Blenkinsop wrote: > > On Mon, Jul 29, 2019 at 2:25 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >> 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. >> > > I'm not sure whether pointer method vs. value method is the distinction > that needs to be made. For the general purpose of writing code that calls > methods on arbitrary types, what we want to know is whether a > type-parameterized function should assume it needs an addressable value or > if it can use a non-addressable value of the parameter type to call a > method. Any references/dereferences that need to be done can be done > automatically as long as you know whether the value needs to be addressable > and the code is written accordingly (i.e. without needing to take the > address of an implicit variable). That might end up being represented in > the language as though you're passing pointers into the methods, but I > don't think that needs to map to whether the concrete method itself accepts > a pointer or a value. > > To illustrate, if you have > > func Foo(type T ...)(slice []T) { > for i := range slice { > slice[i].DoStuff() > } > } > > what sort of bound do you need on `T` so that it can handle each > combination of: > > 1. `T` is passed a value type `Arg` or a pointer type `*Arg`, and > 2. `DoStuff` is defined on `Arg` or on `*Arg`? > > Why you sort of want is a constraint like > > HasDoStuff(T), HasDoStuff(*T) > > where at least one or the other should capture the `DoStuff` method in > each case, and thus the combined constraint should allow you to call > methods on/involving addressable `T` values (potentially based on the > fiction that the accepted type is `*T`). I'm not sure what the best way of > write such a constraint is, though, or how common this kind of case is. > > On Mon, Jul 29, 2019 at 2:25 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >> On Mon, Jul 29, 2019 at 7:05 AM Ilia Choly <ilia...@gmail.com >> <javascript:>> 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 golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWgzkqS4GHH%2BbcQd6KNGJrRd1v2d0D2GU5LsomJF0SL%3Dw%40mail.gmail.com >> . >> >
-- 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/319f905d-e73c-4e63-9ee3-7db2e16895b3%40googlegroups.com.