Memory safe in D

[Richard (Rikki) Andrew Cattermole]

On 27/03/2024 6:56 AM, Quirin Schroll wrote:
> On Tuesday, 12 March 2024 at 03:00:24 UTC, Walter Bright wrote:
>> On 3/11/2024 3:20 AM, Alex wrote:
>>> Oh... looks like null is also used for refs in D. It's sad :)
>>> I thought it used only for pointers in unsafe mode.
>>> I think, the null safety feature is very important in modern world 
>>> (maybe "must have" :) ). Very nice to have such feature in D like in 
>>> Kotlin for example.
>>> So, as I understand, D team have the task in TODO list about 
>>> implementation something like "null safety"?
>>
>> Null is actually not a memory safety issue. What happens when null is 
>> read or written to is a seg fault. The seg fault is the hardware 
>> saying "you cannot do that", so there is nothing unsafe about it.
> 
> I guess what people want instead of segmentation faults is not UB, but 
> compile errors. Segmentation faults are better than UB, but a type 
> system that tells you where your code might segfault because of a null 
> dereference is even better: Not only gives it peace of mind, it works on 
> platforms that don’t segfault, and it’s likewise free of any runtime cost.
> 
> It’s a whole different discussion how to add those compile-time checks 
> to D’s type system.

Yes, and unfortunately it appears nobody except Paul has opinions about 
its existence.

https://forum.dlang.org/post/ucdmmlxklanpsggqmwas@forum.dlang.org

I put a lot of work into type state analysis that deals with 
uninitialized/initialized, nullable/non-null type states.

It has been pretty disheartening to see this thread and then look at my 
proposal for it and there just isn't anyone with counter proposals or 
issues it may bring. Not even Walter saying he sees nothing wrong with 
it currently.