|Posted by Stewart Gordon||PermalinkReply|
According to the documentation, one of the main goals of D is to:
"Reduce software development costs by at least 10% by adding in proven productivity enhancing features and by adjusting language features so that common, time-consuming bugs are eliminated from the start."
Yes, it manages it to an extent. But there are quite a few places where D lets through some signs of bugs that it ought to eliminate.
Let's make a list....
Features to combat bugs:
- unit testing
- design by contract
- garbage collection
- array bounds checking
- requiring explicit initialisation (up to a point....)
- functions are virtual by default
- no more ; as null statement (such as for/if/whatever body)
- no more if (qwert = yuiop) typos to screw up the program
- Compiler-generated default clause in switches
Features to let bugs through:
- default fallthrough on switch*
- implicit narrowing conversions
- the 'no warnings' rule, stopping competing implementations from helping you further to avoid bugs
* This is one place where, IMO, making code that looks like C act like C isn't really an excuse. As I think I said before, no frustratingly subtle bugs would be created by requiring a break or explicit notation of a fallthrough. Moreover, this requirement would be no more breaking C compatibility than the compiler-generated default clause does already.
Features to defer what ought to be compile-time errors to the runtime:
- not all paths through a function required to return something
- allowing auto object references to be declared without initialisation
This list is probably by no means complete. But at least it shows that, while D has done a handful of sensible things to catch bugs, it could do better.
Maybe some of you can think of other things to add....