[generics] no methods with type parameters

[Carsten Orthbandt]

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

 

[T L]

The method set of a type should be stable. Generic methods make this impossible.

[Axel Wagner]

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.

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

[Carsten Orthbandt]

1st: Says who?
2nd: The method set of a type would be stable at runtime since only instantiated methods would exist.

[Carsten Orthbandt]

Reflection certainly is a potential problem. But the only actual issue I can see is the possibility of having multiple methods of the same name on a type.  Obviously, reflect.Type.MethodByName(string) would have to either exclude or somehow distinguish the variants under a single name.

I don't really consider that a real problem since reflect.Type is an interface. The existing incarnations of that interface could simply ignore type-param'ed methods and a new one be added for types that do have such methods. With an added enumeration method for type-param'ed methods on a type.

Just once idea, but the core is: Yes, reflection is an issue, but a solvable one.

Other than that, I don't see how

func A(rcv Rcv,p1 P1, p2 P2)

vs

func (rcv Rcv) A(p1 P1, p2 P2)

would cause trouble for the compiler. Heck, such parameterized methods could be treated as syntactic sugar similar to how early C++ compilers did. As far as I'm concerned, they wouldn't have to show up in the classic reflection at all.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Carsten Orthbandt]

Addendum in case I wasn't clear:

I consider the absence of type-parameterized methods a bigger problem than potentially required extensions to the reflection interfaces. Parens, brackets or smiles for syntax? Yeah, I do have favorites, but it's not a big deal. Contracts or interfaces? I prefer interfaces, but its not a big deal in application. Not being able to orthogonally structure an applications type family? That is a big deal in my view, borderline embarrassing.

[Bebop Leaf]

Using your code as example:

> func (tl *TextList) Add(type T Stringer) (item T ) {
>     tl.Data=append(tl.Data,item.String())
> }

Now if we have:

package pkg //probably written by a user you don't know that uses your code

type A struct{}

func (A) String() string { return "" }

type IA interface { Add(A) }

Does a variable of type  `TextList` implements `pkg.IA` or not?

[Axel Wagner]

You have not responded to the second concern, about interface-type-assertions requiring runtime instantiation of methods.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/aea3bde2-7465-4e5e-8677-9548b55e56e5o%40googlegroups.com.

[Axel Wagner]

Also, just FTR, I agree with you that it would be nice to have type-parameters on methods. I would very much like it if there was a way to make it work.

However, your tone is very confrontational. The people who wrote that design have spent a lot more time on thinking about this than you and you should give them the benefit of the doubt that they wouldn't just leave this out, if the issues were trivial to solve.

[Carsten Orthbandt]

And there goes my illusion about golang-nuts being a constructive discussion.
Thanks, I'm out.