Biggest problems w/ D

[C. Dunn]

After converting a large, system-level program to D, I can name the biggest problems:

1) No stack-trace on exceptions.
This makes contract programming a mere QA test, rather than a useful debugging tool.

2) No 64-bit support.
This not only limits memory usage, but also causes 2x runtime on my AMD processor.  My D code is the same speed as my 32-bit C++ code, but both are 2x slower than 64-bit C++ code.  Same compiler.  Same machine.

3) Lack of forward declarations.
The compiler figures everything out in simple cases, but it gets very confused with templates.  That dramatically hurts the genericity of D, since it limits what templates can do.  One nice use of templates in C++ is to set a static variable on a type, as a sort of "property" with high-speed access.  With D, I have accomplished this only by putting all templates in the same file.

This problem also causes the compiler to depend on the order of files on the command-line.

4) Not enough help for converting between D strings and C char*.
There must be conversion functions which work regardless of whether the D string is dynamic or not, and regardless of whether the C char* is null terminated.  I'm not sure what the answer is, but this has lead to a large number of runtime bugs for me as a novice.

5) Same syntax structs and classes.
This is minor problem, but it is extremely confusing to the novice.  A struct and a class are completely different in D, but the fact that I can write code the same to use either one implies too much similarity.  It leads to programming errors which easily result in seg-fault.

Also, it is too difficult to switch a set of objects from structs to classes or vice versa.  I need to be able to do that in order to compare runtimes for various implementations.  Again, I don't know the best answer.


I love the language as an evolution of C++, so I really hope these problems get ironed out.  I could list a *lot* of great things about D!