Fixing C's Biggest Mistake

[claptrap]

On Sunday, 1 January 2023 at 18:18:57 UTC, Walter Bright wrote:
> On 12/31/2022 7:06 PM, Timon Gehr wrote:
>> No, it absolutely, positively does not... It only ensures no 
>> null dereference takes place on each specific run. You can 
>> have screwed it up and only notice once the program is 
>> published. I know this happens because I have been a _user_ of 
>> software with this kind of problem. Notably this kind of thing 
>> happens in released versions of DMD sometimes...
>
> You're absolutely right. And if I do a pattern match to create 
> a non-nullable pointer, where the null arm does a fatal error 
> if it can't deal with the null, it's the same thing.

That's a logically flawed argument because it rests on the 
assumption that the only possible way to handle a null when 
converting from a nullable to a non-nullable is to abort the 
program.

It's also a strawman because it also misses the point that its 
not about what you do with the null, but knowing where they might 
get in. Statically knowing where the external doors are.


>> That's great. However, it's somewhat aggravating to me that I 
>> am currently not actually convinced you understand what's 
>> needed to achieve that. This is because you are making 
>> statements that equate nonnull pointers in the type system to 
>> runtime hardware checking with segmentation faults.
>
> Yes, I am doing just that.

It's not the same because non-nullables allow you to narrow down 
the places where the abort can happen. It's like putting metal 
detectors on doorways. When someone passes through a metal 
detector they get a id badge, with that badge they can pass 
through any doorway. If there are only 3 external entrances you 
put the metal detectors on those. Now the building is safe. The 
nullable to non-nullable conversions are the metal detectors.