On 8/27/2011 1:14 PM, Benjamin Thaut wrote:
After having used the D 2.0 programming language for a year now and
having completed 3 projects with it, I wrote a small article about the
problems I had with the D 2.0 programming language and what suggestions
I have to improve it.
http://3d.benjamin-thaut.de/?p=18
Comments and criticism welcome
Excellent article. I like the constructive criticism without the "D
will never be better than C++, Walter Bright is an idiot, I will never
use a GC language, D is slow on one benchmark therefore it is poorly
designed and will be slow forever" attitude.
Some of the things you mention are definitely bugs. (I'd call emplace
requiring exact c'tor arguments, TID not supporting shared, the
thread-local storage/GC issue, and maybe no function overloading with
template parameters bugs. The TLS issue is already known.) These have
a lot higher a probability of getting fixed if you file them as bug
reports (see http://d.puremagic.com/issues/ ). Better yet, if yo know
how to fix it, you can submit a pull request to the DProgrammingLanguage
Github page.
Other things you mention are design decisions that are the result of
carefully considered tradeoffs. These include structs not having an
identity, lack of implicit c'tors, and shared. These are tradeoffs that
may not be the best for your situation, but are not unforced errors.
As far as assert, maybe there should be a compiler switch that makes all
asserts behave the way assert(0) does in release mode: Simply issue the
HLT instruction and use a debugger to figure out what went wrong.
However, I think the current behavior of assert is the right default
behavior because it gives clear hints as to what went wrong (and a stack
trace on newer releases) even if you're not running in a debugger.
Associative array invariance may be fixable now using reference
counting. This issue has been in the back of my mind for a long time.
Thanks for bringing it back to the front, and maybe it's worth fixing.
