That's not a random limitation, there are very specific reasons[1] you cannot easily add generic methods as struct receiver functions.
[1] https://go.googlesource.com/proposal/+/refs/heads/master/des...
[1] https://go.googlesource.com/proposal/+/refs/heads/master/des...
I've been using Go as my primary language for a decade, and the lack of generics on methods was surprising to me the first time I ran into it, and the reasoning not obvious.
There's no theoretical reason not to have it, the reason is because of a random intersection of other design decisions... unless you're saying they made those choices fully expecting to have these restrictions on generics later?
What? Methods are not needed if not for implementing an interface?
Anyway, functions could also be implementing interfaces, some languages allow that.
I swear the go docs read like a cult.
And unless you're also using interfaces, methods are no different from functions aside from call syntax.
Methods bind state with a function.
That an object can satisfy an interface is secondary here. In different languages, an interface could be satisfied with a combination of methods, fields, or nominality.
If the statement "we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all" was true, then there should not be a single struct in go (stdlib nor elsewhere) that does not implement some interface (and it must be used via that interface to make sense). This is obviously not the case.
> Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all.
I will say it again: the go docs want to gaslight the reader into believing everything is allright, a design decision, and never a bad one. Constantly. It reads between a cult and a marketing piece, sometimes.
Methods have many more upsides than dynamic dispatch, or else there would be no (or little) methods that don't have an interface. We could all code like it's C, yet we don't. The only times I have been forced into this C style is when I wanted a method with generic parameters.
Don't get me wrong, BTW, I'm not at all a fan of Go overall design and numerous inconsistencies and limitations. But, in this case at least, they have a valid point wrt complexity of the feature (which, to be fair, is largely induced by design of Go's other features, but it is what it is at this point) versus its usefulness. I can only wish for other PL warts of Go to be as minor as this one.
I am okay with go doing lots of type complexity tradeoffs for one of the fastest and leanest compilation times out there. I'm not okay with the go creators consistently gaslighting readers into believing that this tradeoff is not happening. In other words, they want to have the cake (speed) and eat it too (my type system is actually good).
I understand that in this day and age, you are forced to do marketing (manipulate the truth) to make a PL popular. But the go project just does it too blatantly for my taste.