Fixing C's Biggest Mistake

[Walter Bright]

On 12/30/2022 1:46 PM, Nick Treleaven wrote:
> What that buys you is a way to convert a nullable reference to non-nullable, 
> without the possibility of an accidental fatal error.

At some point, you did insert a check. For example, if you have an array of file 
pointers, and want to remove one. Do you compact the array, or just leave a null 
entry? Leaving a null entry is faster, and if you forget to add a check, the 
hardware will check it for you.


> Plus sometimes whole program optimization can remove those checks. The compiler 
> could potentially generate another version of a function taking a nullable 
> parameter, one for a non-nullable reference. Any null path is statically removed 
> in that version.

That's true. And for a null pointer, the null path is statically not there, even 
though the checking remains for free!


>> You still get a fatal error, if the pattern match arm for the null pointer is 
>> fatal.
> 
> If the arm for null is fatal then the programmer must have deliberately opted-in 
> to a fatal error by typing e.g. `assert(0)`. Not accidentally forgetting to 
> handle null, which is a common mistake.

Yes, that's exactly what I was talking about. You've substituted a free hardware 
check for a costly check.


> Unfortunately it's not 100% reliable. If you have a null reference to a type 
> with fields whose offset is big enough to take it into a valid memory address, 
> then that hardware check won't catch it.

Yes, you are correct. I think D has a limit on the size of a struct object for 
that reason.

----

But hey, this discussion is ultimately pointless. D will get sumtypes and 
pattern matching at some point. You can write code in your preferred style - no 
problem!