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? -- 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.
