One way to see a problem pretty immediately is that `reflect` allows you to
look up a type's method by name, but it doesn't allow you to do the same
for functions. So you'd need a runtime-representation of generic functions
of *some* sort. This is currently avoided by the restriction that you can't
refer to an uninitialized generic function.
Another (similar) problem is that you can do interface-type assertions. So,
if you have `func (x *Foo) (type T) X(T)`, a type-assertion of the form
`x.(interface{ X(T) }` would need to succeed for any `T`, even if the
compiler didn't know it was needed. So you need a way to generate
instantiations of generic functions at runtime as well. Those problems are
probably solvable *somehow*, but it should be clear that it's a non-trivial
problem on top of everything else.FWIW, I don't think adding this later will be much of a problem. What's considered idiomatic Go has changed in the past and will continue to change. For example, with the new APIs in the `errors` package, idiomatic error handling is changing. It's fine for things to change if we add type-parameter on methods as well. On Sat, Jun 20, 2020 at 3:32 PM Carsten Orthbandt < carsten.orthba...@gmail.com> wrote: > Hi! > > First, thanks to the Go team for the hard work and the list populace for > an extremely low-noise list. Very much appreciated. > > In the recent draft, struct methods with type parameters are explicitly > excluded with a note that they might be added later. > I think I roughly understand the added complexity of having basically 2D > type parameters (from the struct type itself and the mehtod). > However, and I'm really wondering why nobody brought this up, I think this > is a language element that would be quite akward to add later. > > Not because syntax would have to change in incompatible ways, but because > idiomatic Go will be forced to steer towards global functions for this use > case. > > Minimal example: > https://go2goplay.golang.org/p/CxK7EuhW_fF > > Please note that the struct type in this example does not even use type > parameters. > > With the method receiver really being just a 0th argument to a method, I > don't see why having type params on methods would be such a big challenge. > > > Best Regards, > Carsten > > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/aa570653-56e4-492e-8640-4d4434cd2973o%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/aa570653-56e4-492e-8640-4d4434cd2973o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfG6SufnBSzw340XaHkytsDb0wc8Xr3dewzjLqVi3N49gQ%40mail.gmail.com.
