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.
