On Tue, Sep 11, 2018 at 1:39 PM, roger peppe <rogpe...@gmail.com> wrote: > On 11 September 2018 at 18:04, roger peppe <rogpe...@gmail.com> wrote: >> If it were not explicitly prohibited by the draft proposal, we could >> also imagine this, a definition of a method foo on the type A that's >> parameterised with type T; the method itself has a type parameter S: >> >> func (a A(T)) foo(type S)(s S, t T) > > With respect to this, I wonder if the draft proposal isn't being a bit > more restrictive than necessary. > > I suspect that type parameters on methods might turn out to be very > nice to have (it's very useful to keep within a type's namespace) even > if we can't use them in interfaces or in reflect. > > How about allowing them, but say that methods with type parameters > never appear in any interface and cannot be accessed with reflect?
While methods can be a convenient way to organize code, their only real semantic meaning is to satisfy interfaces. Other than that, they are just a funny way of writing functions. Permitting methods that do not satisfy interfaces seems like a fairly minor feature, and at least at this point I don't think the benefit is worth the confusion. It's always something that can be added later. 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. For more options, visit https://groups.google.com/d/optout.
