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.