"Expressive vs. permissive languages" and bugs

dsimcha dsimcha at yahoo.com
Sat Oct 23 10:29:31 PDT 2010


At a meta level, I never really understood all these calls for more strictness in
D to prevent bugs.  We already have a garbage collector and rules that prevent the
most common C bugs.  I generally find that the vast majority of time I spend
debugging D code (which is more relevant than the number of bugs) comes from one
of two sources:

1.  Cases where I intentionally bypass safety features (for example, using manual
memory management, unsafe casting where the type system is just getting in the
way, or unchecked shared-memory multithreading) for performance or convenience
reasons.  In these cases what's really needed is to make existing safe features
more usable and efficient so I'm not as tempted to bypass them.

2.  High-level/domain-specific logic errors.  About the only language features
that will help here are good abstraction capabilities (so I only need to get
complicated algorithmic code right once, and can then reuse it) and good
contracts/asserts (which D mostly has, though I'd love an alwaysAssert() or
something that throws an AssertError instead of Exception, like assert(), but
isn't compiled out in release mode, like enforce(),).  One other thing that might
help here is finer grained control over bounds checking.  I'd love to leave bounds
checking on for most of a program, but turn it off just for certain
performance-critical classes/structs/functions.


More information about the Digitalmars-d mailing list