On 11 September 2018 at 22:46, Ian Lance Taylor <i...@golang.org> wrote: > 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.
Yup, definitely. -- 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.
