• Stewart Gordon (36/36) Oct 06 2004 According to the documentation, one of the main goals of D is to:
• J C Calvarese (9/14) Oct 06 2004 IMO, competing implementations can offer all of the warnings under the s...

Stewart Gordon <smjg_1998 yahoo.com> writes:

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.

J C Calvarese <jcc7 cox.net> writes:

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