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:

- Object.opCmp
- 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....

Stewart.

In article <ck16lu$2os4$1@digitaldaemon.com>, Stewart Gordon says...

[snip]

>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

IMO, competing implementations can offer all of the warnings under the sun if the implementors so choose. I think Walter's only request is for the default setting to be "no warnings" mode (or at least make it easy to turn off all of the warnings). That way if one compiler goes wild and produces thousands of warnings on /valid/ code, then that code can still be compiled with the warnings turned off.

jcc7