I've been thinking some more about this and, assuming that Patrick and I
are right that an instantiated type can have its own method set, there are
going to be some severe ambiguities when defining generic functions i.e.
it's not always going to be clear whether T is a type parameter or an
actual type!
Two possible solutions spring to mind:
1. Methods of a parameterized type should repeat the 'type' keyword:
func (type x Foo(int)) Bar() {} // `int' is a type parameter in
relation to Foo(type T)
func(x Foo(int)) Bar() {} // `int` is an actual type and Foo(int) is an
initialized type
2. An initialized type cannot be used directly as a method receiver, it
must be type-aliased first:
func (x Foo(int)) Bar() {} // `int' is a type parameter in relation to
Foo(type T)
type FooInt = Foo(int)
func (fi FooInt) Bar() {} // no type parameters now so clearly a method
of FooInt
Of these I think I prefer #2 on clarity grounds.
Another problem is whether FooInt will include in its method set not just
its own (non-generic) methods but the methods of Foo(type T) where T is an
int. My answer to that is yes, I think it will need to do so. What do you
guys think?
Generics really is a can of worms!
--
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.
