4 ms·

No need to wonder. The proposal goes into lengthy detail as to why they are not included. There is hope that they will be added in the future, but solutions to

No need to wonder. The proposal goes into lengthy detail as to why they are not included. There is hope that they will be added in the future, but solutions to the problems will need to be found first.

kubb 5y ago
I wouldn't call it lengthy, but if anyone is wondering, the proposal points out that parametrized methods don't have an obvious behavior _inside interfaces_. No mention of why they left them out in non-interface types.
- Ericson2314 5y ago
  Yeah they are just being ignorant once again. Even "static" interface usage, a la Rust Traits, is fine. But Go doesn't distinguish between the static stuff and the dynamic vtable stuff very well at all. That's the problem they should fix.
  - randomdata 5y ago
    > Yeah they are just being ignorant once again. That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept. It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.
    - saghm 5y ago
      It seems plausible that some people who might otherwise want to have decided not to given the very vocal contingent of the Go community that's been opposed to generics. After almost a decade of people saying Go didn't need generics, it seems like it would be hard to convince people who are knowledgeable in that field that their efforts would be welcome.
      - randomdata 5y ago
        The core Go team has been working on generics since the pre-1.0 days and have submitted many different generics proposals over the years to reflect that. They all, until the latest one, failed for one reason or another, but shared property of them all was being created by those who were not experts in the domain. It is why the latest incarnation brought in an external consultant to help guide the team in the right direction. There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.
        andrekandre 5y ago
        what is the major difference of go generics vs say c# or swift generics that makes the long wait worth it for go? was there any major breakthroughs?
        randomdata 5y ago
        I don't expect you will find any major difference, hence why the number of people who cared about generics in Go was effectively nobody and why very few were stepping up to contribute: They already had many other languages to choose from.
        xh-dude 5y ago
        It seems significant (major? I dunno) that Go doesn’t have inheritance or subclassing or co-/contra-variance.
  - philosopher1234 5y ago
    You sound like someone who doesn’t know very much about Go.
- mseepgood 5y ago
  In Go any type can implement interfaces. A type doesn't declare which interfaces it implements.
  - masklinn 5y ago
    That doesn't seem like a relevant objection? If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement. The reverse would be an issue, but this is not.
- crtc 5y ago
  > No mention of why they left them out in non-interface types. Actually it does: "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." 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...
  - erik_seaberg 5y ago
    Except that reflection-based tools work with methods but not functions.
    - crtc 5y ago
      Yes, but reflection is part of the problem: "And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable." So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.

kubb 5y ago

I wouldn't call it lengthy, but if anyone is wondering, the proposal points out that parametrized methods don't have an obvious behavior _inside interfaces_. No mention of why they left them out in non-interface types.

Ericson2314 5y ago
Yeah they are just being ignorant once again. Even "static" interface usage, a la Rust Traits, is fine. But Go doesn't distinguish between the static stuff and the dynamic vtable stuff very well at all. That's the problem they should fix.
- randomdata 5y ago
  > Yeah they are just being ignorant once again. That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept. It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.
  - saghm 5y ago
    It seems plausible that some people who might otherwise want to have decided not to given the very vocal contingent of the Go community that's been opposed to generics. After almost a decade of people saying Go didn't need generics, it seems like it would be hard to convince people who are knowledgeable in that field that their efforts would be welcome.
    - randomdata 5y ago
      The core Go team has been working on generics since the pre-1.0 days and have submitted many different generics proposals over the years to reflect that. They all, until the latest one, failed for one reason or another, but shared property of them all was being created by those who were not experts in the domain. It is why the latest incarnation brought in an external consultant to help guide the team in the right direction. There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.
      - andrekandre 5y ago
        what is the major difference of go generics vs say c# or swift generics that makes the long wait worth it for go? was there any major breakthroughs?
        randomdata 5y ago
        I don't expect you will find any major difference, hence why the number of people who cared about generics in Go was effectively nobody and why very few were stepping up to contribute: They already had many other languages to choose from.
        xh-dude 5y ago
        It seems significant (major? I dunno) that Go doesn’t have inheritance or subclassing or co-/contra-variance.
- philosopher1234 5y ago
  You sound like someone who doesn’t know very much about Go.
mseepgood 5y ago
In Go any type can implement interfaces. A type doesn't declare which interfaces it implements.
- masklinn 5y ago
  That doesn't seem like a relevant objection? If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement. The reverse would be an issue, but this is not.
crtc 5y ago
> No mention of why they left them out in non-interface types. Actually it does: "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." 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...
- erik_seaberg 5y ago
  Except that reflection-based tools work with methods but not functions.
  - crtc 5y ago
    Yes, but reflection is part of the problem: "And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable." So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.