4 ms·

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

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/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...

abound 2y ago
For someone not well-versed in language implementation details, it may very well feel random. 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.
- rendaw 2y ago
  Yeah. I'm not claiming they didn't back themselves into a corner here. 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?
the_gipsy 2y ago
> 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. If we disregard interfaces, any parameterized method can be implemented as a parameterized function. 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.
- int_19h 2y ago
  Functions in Go can be generic, just not methods. And unless you're also using interfaces, methods are no different from functions aside from call syntax.
  - the_gipsy 2y ago
    But "methods are only needed because of interfaces" is simply not true. Not true in all other OOP languages that I know of, not true in go, and not true in go's stdlib (that is, in practice). 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.
    - int_19h 2y ago
      If the method is not dynamically dispatched, it is exactly equivalent to a function with receiver passed as the first argument. The receiver-dot notation is just a convenient form of implicit namespacing, then, nothing more. And, in Go, methods are only dynamically dispatched on the receiver in the context of interfaces. So, everything else is just syntactic sugar. And what the doc is saying is that supporting this syntactic sugar makes the spec much more complicated, so they deemed it not worthwhile, given that a global function works just as well in this context.
      - the_gipsy 2y ago
        Yes, we all know what dynamic dispatch is, which is exactly what the docs talk about. > 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.

abound 2y ago

For someone not well-versed in language implementation details, it may very well feel random. 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.

rendaw 2y ago
Yeah. I'm not claiming they didn't back themselves into a corner here. 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?

the_gipsy 2y ago

> 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. If we disregard interfaces, any parameterized method can be implemented as a parameterized function. 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.

int_19h 2y ago
Functions in Go can be generic, just not methods. And unless you're also using interfaces, methods are no different from functions aside from call syntax.
- the_gipsy 2y ago
  But "methods are only needed because of interfaces" is simply not true. Not true in all other OOP languages that I know of, not true in go, and not true in go's stdlib (that is, in practice). 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.
  - int_19h 2y ago
    If the method is not dynamically dispatched, it is exactly equivalent to a function with receiver passed as the first argument. The receiver-dot notation is just a convenient form of implicit namespacing, then, nothing more. And, in Go, methods are only dynamically dispatched on the receiver in the context of interfaces. So, everything else is just syntactic sugar. And what the doc is saying is that supporting this syntactic sugar makes the spec much more complicated, so they deemed it not worthwhile, given that a global function works just as well in this context.
    - the_gipsy 2y ago
      Yes, we all know what dynamic dispatch is, which is exactly what the docs talk about. > 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.