Memory safe in D

[Don Allen]

On Wednesday, 13 March 2024 at 19:58:24 UTC, Steven Schveighoffer 
wrote:
> On Wednesday, 13 March 2024 at 19:36:01 UTC, Alex wrote:
>> On Wednesday, 13 March 2024 at 18:20:12 UTC, Steven 
>> Schveighoffer wrote:
>>> - The path D takes is, let the hardware solve it.
>>> - The path Java takes is to instrument dereferences on 
>>> possibly-null variables and throw an exception if it's null.
>>> - The path many other languages take is to force you to 
>>> validate it's not null before using it.
>>
>> Rust doesn't allow null references at all (exclude unsafe 
>> code). It is one more alternative path.
>
> Then "optional" types, basically the same thing. Null is a 
> memory safe "invalid thing".

I haven't read this whole thread, but I've seen responses to the 
above, and I'd like to add my own comment. The difference between 
null and optional types in Rust is that the Rust compiler forces 
you to handle an optional type in order to obtain its value. You 
can't get at the value without processing the optional with a 
'match' (or related constructs, such as 'if let'), which requires 
handling both possibilities -- Some and None. The compiler 
therefore forces you to handle the unusual case, so if it 
happens, the result will be something under your control.

Null and other unexpected values are simply not equivalent. You 
are not forced to provide code to handle the possibility of the 
unexpected value. When your code blindly forges ahead, you may 
get a seg-fault. Depending on how the code was compiled, you may 
or may not be headed for a session with gdb.

Related to the above, you may also process an uninitialized 
value, at which point anything can happen. To me, this is one of 
the weak spots in D, inherited from C. It can lead to an 
incorrect result returned without error. D's use of default 
initializers (as opposed to C's random garbage) does not fully 
protect against this. Rust does prevent this.