This text seems somewhat contradictory: The function Init cannot be instantiated with the type MyInt, as that type > does not have a method Set; only *MyInt has Set. >
... > If a method is listed in a contract with a plain T rather than *T, then it > may be either a pointer method or a value method of T. > The intent seems to be that a contract that constrains *T is *more specific* than a contract that constrains T. It requires the conditions needed for initialization, on both the caller and callee side. It's the inability to make a sufficiently specific contract that makes the current choice to allow calling pointer methods on values based on a T constraint unfortunate. Initialization is an important use case, but so is updating, and being able to rely on consistent behaviour when it comes to methods that update the receiver—for both the caller and generic callee—makes code easier to reason about. Interfaces get this right and it would be a shame to lose it with generics. The use case I posted earlier—of being able to update values in a slice using a pointer method—would be nice to have supported as well, but not at the expense of the more common case. I'm not sure what the answer is. Perhaps contracts could allow you to use a pseudo-type like &T denoting addressable T values, and let the compiler figure out matching up levels of indirection between generic code and the methods it calls, but this might add more complexity to the design than it's worth. On Mon, Aug 5, 2019 at 7:55 AM, <alan.f...@gmail.com> wrote: > For those who haven't already noticed, I thought I'd point out that the > draft design has now been changed (as Ian intimated it might be) so that > contracts may now require a pointer method in some cases i.e. if the type > parameter is T one can now specify that *T has a certain method. > > In particular, this will be needed if an implementing function is > declaring a variable of type T but you then need to invoke a method on it > where the receiver type is *T. To understand why this is so, one needs to > re-read the design paper which has some examples of why the previous > situation didn't work. > > Looked at overall I think this is a better idea than what I was proposing > earlier, though it might be difficult for folks to get their heads around > the circumstances when and why a pointer method is needed. However, as it's > probably a situation which will arise infrequently in practice, it should > not be a major concern. > > Alan > > -- > 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/64567134-2fec-423c-8828-fed14f392fc7%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/64567134-2fec-423c-8828-fed14f392fc7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANjmGJswmnFkA7pHCLDhBF24ttcSVxBD%2BjPsdEKpH_GA4sPk9g%40mail.gmail.com.
