How does D improve design practices over C++?

[Christopher Wright]

Tony wrote:
> Or if one wanted something like that in C++:
> 
> class MyInvariant
> {
>     MyInvariant(long& x)
>     {
>         // do a check on entry
>     }
> 
>     ~MyInvariant()
>     {
>         // do a check on exit
>     }
> };

There are a couple problems with that solution:
1. The assertions are nowhere near the code they apply to. This makes it 
more difficult to read the code -- both the assertions and the method 
they apply to.

2. It's more code to write. That makes it less likely that you're going 
to write it. In D, I use contracts because they're so easy to use. Your 
C++ alternative isn't nearly as easy, so I wouldn't use it.

3. There is no straightforward, simple way to remove these contracts in 
a release build, if I want extra efficiency. You have to use #ifdef 
DEBUG in a lot of places to get that effect.

4. There's no consistent structure. This also hurts readability.

Personally, I really hate the idea of using RIAA for this kind of thing. 
It's just such a hack. I only want to use RIAA for things that should 
only live for the length of a given function.

Of course, C++ is Turing complete, so there's no feature in D that you 
can't replicate in C++. In the worst case, you can alter DMD (which is 
written in C++) to compile and run your D program.