On Tue, Sep 11, 2018 at 5:46 PM, Ian Lance Taylor <i...@golang.org> wrote:
> > While methods can be a convenient way to organize code, their only > real semantic meaning is to satisfy interfaces. They also represent a limited form of type-directed function overloading. A package can contain multiple methods with the same name as long as they have different receiver base types. And because of how interfaces and embedding work, we can even think of exported methods as inhabiting universal scope. While the main utility of "overloading" a method name is to allow different types to satisfy the same interface, with the contracts proposal they can also serve to allow multiple types to satisfy the same contract. Even with Roger Peppe's more limited contracts counterproposal, methods that can't satisfy interfaces could be required based on a method expression call without needing to deal with all the ambiguities of permitting ordinary method call syntax. Allowing generic methods to be specified in contracts by using method expressions has the property that a contract could only require particular instantiations of a particular method, so a contract couldn't require, say, `T.M(U)(t, ...)` for any type `U`, but instead only for particular type arguments. This simplifies the problem of needing to provide a runtime hook for different instances of the method—you only need the ones specified by the contract—and removes the full generality that might creep too close to allowing C++-style metaprogramming. > -- 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.
