How does D improve design practices over C++?

[Robert Fraser]

Tony wrote:
>>>> - Modules
>>> If that means doing away with header files, I don't think I like it. I 
>>> rely
>>> on headers as the engineer's blueprint (of course you have to write very
>>> clean code to have that make sense).
>>>
>> You missed that one, again. You can have headers in D, too.
> 
> Yes, I don't really know "modules" other than what they obviously imply: 
> separate compilation units/namespaces?

It means you don't have to specify everything 2 times if you don't want 
to (you can if you feel the need). So if you change a function's 
signature, you just friggin' change it, you don't change it at the 
function and in the header. This also makes compilation times much 
faster, since the header files don't need to be included & recompiled 
during every compilation -- if you're compiling a group of files that 
depend on one another at once, the compiler will only compile each one 
once. And, yes, better/automated namespacing.

>>>> - Garbage collection
>>> That's a major deal breaker for me.
>>>
>> You can turn it off and do the memory management by yourself, if you wish:
>>
>> struct Foo {}
>> Foo* foo = new Foo();
>> delete foo;
> 
> And if I don't want to use new and delete?

Then you use the GC. Or malloc/free. Or placement new. Or... seriously, 
what do you want here?

>>>> - Delegates (Specifically, encouraging there use by making them simple 
>>>> to
>>>> use)
>>> Can't comment.
>>>
>> This is an awesome feature, too bad you don't have this one in C++. You 
>> will like it, believe me!
> 
> Well what the heck is it?!

It's a function pointer with context. So you can point to a member 
function, for example.  In D2, there's also closures so...

void main(string[] args)
{
     auto dg = getADelegate();
     writefln("%d", dg());
     writefln("%d", dg());
     writefln("%d", dg());
}

int delegate() getADelegate()
{
     int i = 0;
     return delegate int() { return ++i; };
}

Will yeild:
1
2
3