5 ms·

Go doesn't do inheritance either. It has type embedding, but it's not the same. In the most recent of Ian Lance Taylor's proposals (Type parameters, 2013 [1])

Go doesn't do inheritance either. It has type embedding, but it's not the same. In the most recent of Ian Lance Taylor's proposals (Type parameters, 2013 [1]) he summarizes: > The implementation description is interesting but very complicated. Is any compiler really going to implement all that? It seems likely that any initial implementation would just use macro expansion, and unclear whether it would ever move beyond that. The result would be increased compile times and code bloat. So I'm pretty sure that the logic is acceptable, but it conflicts with Go's core goals of simplicity and compilation speed. [1]: https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md https://github.com/golang/proposal/blob/master/design/15292/...

masklinn 11y ago
> Go doesn't do inheritance either. It has type embedding, but it's not the same. It does have interfaces though.
- Intermernet 11y ago
  This is generally brought up as the reason that Go doesn't need generics. I tend to agree with this. I've yet to come across a use-case where the current system is too difficult to deal with, but there are other people who have hit this limitation. Maybe this can be solved by simply modifying the parsing of the keyword "type" (Or adding a reserved type "T") and telling developers that the functionality of "go generate" will automatically (in the compiler) expand and create type methods at compile time, and build the type generation into the compile phase, rather than a manual pre-compilation phase. I haven't considered the problems with this approach, but I assume Ian et al have. It seems to me that the generated code approach could be spliced into the compiler with a few key-word parsing changes, but I'm not going to assume that the Go team haven't already thought of this, and there are probably problems with the idea that I haven't considered, above and beyond spec / compatibility promises etc.
  - masklinn 11y ago
    > This is generally brought up as the reason that Go doesn't need generics. Which I find nonsensical, but my point was that Go's interfaces are a form of subtyping, which as eru and tel note tend to have challenging interactions with generics.

masklinn 11y ago

> Go doesn't do inheritance either. It has type embedding, but it's not the same. It does have interfaces though.

Intermernet 11y ago
This is generally brought up as the reason that Go doesn't need generics. I tend to agree with this. I've yet to come across a use-case where the current system is too difficult to deal with, but there are other people who have hit this limitation. Maybe this can be solved by simply modifying the parsing of the keyword "type" (Or adding a reserved type "T") and telling developers that the functionality of "go generate" will automatically (in the compiler) expand and create type methods at compile time, and build the type generation into the compile phase, rather than a manual pre-compilation phase. I haven't considered the problems with this approach, but I assume Ian et al have. It seems to me that the generated code approach could be spliced into the compiler with a few key-word parsing changes, but I'm not going to assume that the Go team haven't already thought of this, and there are probably problems with the idea that I haven't considered, above and beyond spec / compatibility promises etc.
- masklinn 11y ago
  > This is generally brought up as the reason that Go doesn't need generics. Which I find nonsensical, but my point was that Go's interfaces are a form of subtyping, which as eru and tel note tend to have challenging interactions with generics.