News for hackers. Stuff that matters.
Re:C++ in Coders at Work by jbooth on Tuesday February 15, 2011 @11:47AM (#2221947)
Well, adding generics shouldn't break working code.. it's an additive change.

It says something that for the built-in collection types, Slice and Map, they had to hack around their own API and implement this-case-only ad hoc generics. Slice and Map should be fully implementable within the language.

Re:C++ in Coders at Work by supersillyus on Tuesday February 15, 2011 @12:47PM (#2222278)
Why should Slice be fully implementable within the language? C++ is another systems language that decided that everything should be able to be done in libraries, and we've all seen the complexity that results.
Re:C++ in Coders at Work by jbooth on Tuesday February 15, 2011 @01:42PM (#2222566)
Well, I'll back off slightly from the assertion "fully implementable" because you have the f = s[i] syntax which wouldn't be fully implementable unless you allow the user to define [], which I agree is crazytown.

However, the make() functions for slice and map are the only functions in the language that allow you to pass in a type and get that type back as a return function. Why can't users have that functionality? Generics seem to be the easiest way to get it.

Re:C++ in Coders at Work by supersillyus on Tuesday February 15, 2011 @06:48PM (#2224011)
I think I agree, but I'm not good enough at language design to be sure. :) In the current language, all uses of type literals need to be known at compile time; if I could pass a variable containing a type to "make" or use it to instantiate a map, the language needs generics to deal with that, and all of the complications that come with it. The current idiom seems to be (if I wanted my own "make"):

myslice := mymake((MyType)(nil), 10).([]MyType)

which is much uglier than the built-in way. However, I'm kinda okay with reflection-laden runtime tomfoolery looking a bit messy, mostly because I rarely use it, and when I do I like it to stand out and be obvious what is going on.