5 ms·
To be clear, generics seems to be one thing that Go isn't actually opinionated on. As I understand it, they are open to including generics in future versions o
by jlgreco 14y ago
To be clear, generics seems to be one thing that Go isn't actually opinionated on. As I understand it, they are open to including generics in future versions of the language, but only if the implementation is elegant.
- _ak 14y agoWell, as far as I understand, that implementation would need to overcome the Generic Dilemma as described by Russ Cox: http://research.swtch.com/generic http://research.swtch.com/generic So far, the Go team decided to go for approach #1.
- maaku 14y agoOption #3 is unfairly presented. There is no reason a language couldn't implicitly box every type, but automatically create efficient specializations for (some of) the types actually used. You can have your cake and eat it too. Of course, it's not easy to write such static optimizations. But it is, in principle, possible, and the sort of thing you only need write once.
- dualogy 14y ago> But it is, in principle, possible, and the sort of thing you only need write once. Well Go is open source so "someone" would just have to write, test and submit a CL / patch... ;-)
- masklinn 14y ago> So far, the Go team decided to go for approach #1. Except where they personally really wanted parametric polymorphic collections so they baked them as special case into the runtime, of course (map, chan, …)
- codeflo 14y agoIn a sense, they went for #3 (auto-boxing) without the syntactic sugar. Casting int to interface {} has a similar overhead to boxing in Java.