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.
[ Parent
| on HN ]
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.