Three Unlikely Successful Features of D

[H. S. Teoh]

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.