"Walter Bright" <[email protected]> wrote in message news:[email protected]... > 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* nullable types are completely disallowed, then yes, using non-nullables exclusively would probably lead to hacks that create subtle corruption. But that doesn't matter because nobody here is arguing for that. What is being argued for is for non-nullables to supplement nullables. In this scenario, things like the DesignatedNullObjectThatsNotActuallyNullToShutUpTheCompiler don't remotely enter into the picture (or at least no moreso than they do already). What happens instead is simply that the programmer is now allowed to say "Hey compiler, this code doesn't deal with the possibility of a null on this param, so don't let anyone pass in something that could be null...that way it'll never corrupt *and* never crash." That's all it is. No error that was previously non-hidden becomes hidden here. Of course, there is still one other requirement to pull this off without risking encouragement of those FakeNull objects (which I agree can hide errors, although we should remember they're still a real possibility even the way D currently is). We'd need a basic ability to track potential null-ness at compile-time, so that actually getting values into those non-nullables wouldn't be hindered. That is getting towards uninitialized-value-tracking, but that's a direction we really should be headed anyway (it really does work great in C# with very, very simple rules, no holy-grain needed...in fact, lack of holy-grail is preferable, but I've already made that argument weeks ago). > 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. No, he's using the real meaning of "safe", not the misleadingly-limited "SafeD" version of "safe" (which I'm still convinced is going to get some poor soul into serious trouble from mistakingly thinking their SafeD program is much safer than it really is). Out here in reality, "safe" also means a lack of ability to crash, or at least some level of protection against it. You seem to be under the impression that nothing can be made uncrashable without introducing the possibility of corrupted state. That's hogwash.
