I think it would work with interfaces if the interfaces (generic or
not) can themselves specify generic methods, like
interface {
Foo(type T)(T) T
}
You need to be able to invoke methods on a generic type where the
method is not specialized for the instantiation so I don't see why it
should cause any issues with reflection beyond what's required anyway.
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?
>
> --
> 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.
--
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.
