Can't say I've a strong feeling one way or another on that though there'd be an awful lot of brackets if it were allowed!
You can, of course, always work around it with a top level function: func foo(type S, T)(a A(T), s S, t T) On Tuesday, September 11, 2018 at 9:39:23 PM UTC+1, rog wrote: > > On 11 September 2018 at 18:04, roger peppe <rogp...@gmail.com > <javascript:>> 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.
