Walter Bright Wrote: > language_fan wrote: > > The idea behind non-nullable types and other contracts is to catch these > > errors on compile time. Sure, the code is a bit harder to write, but it > > is safe and never segfaults. The idea is to minimize the amount of > > runtime errors of all sorts. That's also how other features of statically > > typed languages work. > > > I certainly agree that catching errors at compile time is preferable by > far. Where I disagree is the notion that non-nullable types achieve > this. I've argued extensively here that they hide errors, not fix them.
If you argued any cases other than there's no good default initialization, I missed it. I reject the default initialization argument. I find code that relies on default initialization hard to read. I also find C#'s warning of uninitialized variables highly useful. I've also never had a bug that Don's signalling nans would help with. I've had nan bugs that cropped up later though... On top of that, use of a null variable because it was never set are typically easy to find. > Also, by "safe" I presume you mean "memory safe" which means free of > memory corruption. Null pointer exceptions are memory safe. A null > pointer could be caused by memory corruption, but it cannot *cause* > memory corruption. I reject this argument too :( To me, code isn't safe if it crashes. Did Boeing avoid checking for fault modes that were easily and reliably detectable? It seems stupid to argue that it's ok for an altimeter can send bogus data as long as it's easy to detect. All you have to do is turn off autopilot. Who cares, right? Why should I use D for production code if it's designed to segfault? Software isn't used for important things like autopilot, controlling the brakes in my car, or dispensing medicine in hospitals. There's no problem allowing that stuff to crash. You can always recover the core file, and it's always trivial to reproduce the scenario... Mix in other things like malfunctioning debug data, and I wonder why I even use D.
