3 ms·
Well, 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://
by _ak 14y ago
Well, 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.