The following is a list of some of the main defects of C++, as seen by Yossi Kreinin: http://yosefk.com/c++fqa/defective.html
So I have tried to see how D1/D2 score in such regard. In the following list * denotes a point that (I think) D doesn't address enough. Note that I'm ignorant of C++ and my experience of D has so holes still, so it's probable for me to have done several mistakes. (If you are kind you may help fix my mistakes). 1) No compile time encapsulation: "In naturally written C++ code, changing the private members of a class requires recompilation of the code using the class." I think D solves this problem, you only have to compile the module the contains the class (generally a module contains related classes/functions). 2) Outstandingly complicated grammar: D isn't a simple language, but I think more or less solves this problem (it was one of the points of creating D in the first place). 3) No way to locate definitions: I think this is solved. 4) No run time encapsulation: this is fixed regarding array bounds (but not regarding other things). You can even compile some modules with "-release" and others without. 5) No binary implementation rules: fixed, more or less. *6) No reflection: I think D already keeps at runtime most of the relevant data, but the current ways and syntax to use it aren't enough. *7) Very complicated type system: this is quite difficult to fix, maybe it can't be fixed. 8) Very complicated type-based binding rules: I think this is more or less fixed. 9) Defective operator overloading: I think this is fixed. 10) Defective exceptions: I think this is fixed. *11) Duplicate facilities: this isn't fixed. The author says the following, but things aren't so easy: "there's absolutely NO technical reason to parse C-like syntax in order to work with existing C code since that code can be compiled separately." In D several things can be done in the D way or C way. This is good because it allows you to convert C code to D quickly, but increases the language complexity (see static ways to define a struct, plus the way introduced by D), makes some C syntax not available for something better in D, and probably confuses D newbies too (or generally people that will try to learn D with little/no prior knowledge of C). So I think removing some C ways, expecially the most redundant or error-prone may be good. 12) No high-level built-in types: D has some very useful built-in data structures, but they lack several useful methods (lazy views, dict cleaning, dict equality, etc etc) and one or two more can be added (a set? Multiprecision integer? A duck type?). 13) Manual memory management: fixed. 14) Defective metaprogramming facilities: there's always space for improvements. 15) Unhelpful standard library: Tango, etc, I think this is fixed enough. 16) Defective inlining: I think this is fixed. 17) Implicitly called & generated functions: I think this is mostly fixed. So I think D comes out well, the main points missing still are a better reflection, better builtins, and some more C redundancy removed. Bye, bearophile
