(non)nullable types

[Don]

Sebastian Biallas wrote:
> Christopher Wright wrote:
>> Sebastian Biallas wrote:
>>> Christopher Wright wrote:
>>>> Oh, and I vote no. I think it's needless complexity. I code without 
>>>> any special care for null objects, and I get a segfault or 
>>>> NullReferenceException maybe once a week, probably less. I've always 
>>>> been able to track down the bug very quickly.
>>>
>>> That misses the point completely. It's not about you (as the 
>>> programmer) getting NPEs; it's about the user getting bug-free 
>>> software in the first place.
>>>
>>> In most cases a segfault/NPE is easy to track down for the 
>>> programmer, I guess nobody would object to this. But once the 
>>> software is shipped, it's a very serious problem: It's a situation 
>>> the programmer didn't thought about so you usually have a data loss.
>>
>> Your language features should get rid of bugs that are easy to make 
>> and difficult to track down. It's not worthwhile to alter your 
>> language to remove easily found, easily fixed bugs.
> 
> Once your software is running, an easy to fix bug is just as bad as an 
> hard to fix bug. It's a bug after all.
> 
> Of course, you can ask the question whether it's worthwhile to alter the 
> language. Well, for D this is still possible, while other languages will 
> have NPEs till the end of the world.
> 
>> Logic errors are difficult to find. Your language cannot help you 
>> eliminate those (though contracts and unittests can help you find them). 
> 
> "We shouldn't try to avoid bugs of type A because we can't avoid bugs of 
> type B" is a logical fallacy.
> 
>> If you do not test your software extensively, you will ship software 
>> with logic errors. The testing required to find logic errors will also 
>> find low-level errors like segfaults.
> 
> Uh.... sorry, but reality proves you wrong. I (and the rest of the 
> world) get NPE in various kinds of extensively tested software.
> 
> And we can get rid of *all* these errors by a simple language change (A 
> change that should have been done centuries ago). This is a case where 
> you can automatically proof correctness of a specific detail of your 
> software. A chance that shouldn't be ignored because, uh, it's an easy 
> to fix bug (If your rocket to the moon explodes because of an easy to 
> fix bug, well, I don't think that is helps you that it was at least an 
> easy to fix bug).

Agreed. NPE are normally an easy to fix, easy to diagnose bug, but it 
can be *extremely* difficult to trigger a case when it occurs.

Thus, trigger a run-time assert does not help AT ALL. Only a 
compile-time check will do.