On Tue, Mar 20, 2012 at 06:58:31PM -0400, Nick Sabalausky wrote: > - Type inference
Yeah I forgot about this one. Being able to write: auto veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); is a big boon over C++ or Java's stuttering verbosity: VeryLongNamedClass veryLongNamedObject = new VeryLongNamedClass(veryLongArguments); Plus, it's immensely useful when dealing with Range templates... can you imagine the horrifically long typenames you'd have to type you have to explicitly specify the type of a long chain of functional expressions involving 15+ std.algorithm and std.range templates? > - alias This, together with static ifs and templates, make for awesome tricks involving templates that would've been an utter bear to pull off in C++. template innerKeyType(T) { static if (is(T U : U[K], K)) alias innerKeyType!K innerKeyType; else alias T innerKeyType; } innerKeyType!(int[string[char[byte]]]) innerKey; [...] > - Built-in associative arrays that support nearly any type as a key This is actually quite buggy right now... but that's merely an implementation issue. :-) My new AA implementation, for example, already correctly supports AA's with AA keys, which can be arbitrarily nested. So you could have something like int[string[char[byte]]], and it does lookups correctly based on the contents of the AA's you pass in as key. > - All the niceities of ctors compared with C++'s ctors C++ ctors are a royal pain in the neck. I remember in the early days of C++ when you can still call the base class ctor in the body of the derived class ctor... nowadays you have to contort ctor code into a horrible ugly mess just to get your ctor to do things right. Plus, the C++ standard requires fields to be initialized in declaration order, which is needlessly restrictive and basically makes ctors even more of a pain. I ended up using just stub ctors for a lot of my code, and doing the actual initialization after the object is constructed. Which is very bad OO style, I agree, but the pain of working with C++ ctors just pushes me in the wrong direction, y'know? > - Scope guards (And even finally: I head somewhere C++ doesn't even have > finally: Is that true?!?) Yes, it's true. I don't know about C++11, but certainly the previous standard has no finally clause, leading to horribly unmaintainable and ugly code like: Resource r = acquireResource(); try { doSomethingDangerous(); } catch(...) { r.release(); } r.release(); (Yes, yes, I know, RAII and all that... which leads to inventing ridiculous classes which make no sense in terms of OO, just to wrap resource handles.) > - GC For all the warts the current GC has, the fact that D has a GC at all makes things like array slicing possible, and *fast*, which leads to all the other niceties of slicing. > - Name any of D's metaprogramming features [...] > Alias in particular is a much bigger deal than it seems since it's > seemingly trivial but can be *incredibly* helpful with templates *and* > with importing. Definitely. Using alias and static if in a recursive template is one of the hallmarks of the awesomeness of D templates. > Actually, looking at this list, I'm now starting to get a little worried > about an upcoming C++ project... No doubt I'll be trying to reinvent a lot > of D in it. Probably in ugly hackish ways. [...] #include "dmd.h" ;-) T -- Don't modify spaghetti code unless you can eat the consequences.