Haskell doesn't have null, so Optional is the usual alternative (actually called "Maybe" in Haskell, but it's the same thing)

Haskell values can throw exceptions (e.g. for division-by-zero, etc.); but catching them (and therefore branching on them) is an IO effect.

That sort of exception is treated like an unfortunate necessity in Haskell; and user code tends to use a more structured, well-typed approach like Either (there are a few alternatives floating around in common libraries)

Zig does as well. Looks like "null needs some abstraction, and exceptions are way too complex" is the current consensus, at least in some fields.

http://go/rs:std::ptr::null

  Function std::ptr::nullCopy

  pub const fn null<T>() -> *const T

> Creates a null raw pointer.

Perhaps "Safe Rust" would be more apt (de-referencing any pointer is unsafe), though I think it's quite fine and well accepted to refer to "Safe Rust" as just "Rust".

Of course, the null pointer can still exist in Safe Rust, but since you can't de-reference it I think it's fine to say Safe Rust is "close enough" to count.

You can only dereference raw pointers from within an unsafe block so they're only useful inside unsafe blocks. IMO Unsafe Rust != Rust, unsafe is an extension to the language that is clearly separated from safe code, and using it essentially means voiding Rust's safety contract.

Not that you're incorrect but to be even more precise, and for the readers who do not know about Rust, I would say "voiding *parts* of Rust's safety contract".

Citing the documentation:

> To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust, called unsafe superpowers, that you can’t in safe Rust. [...]:

> - Dereference a raw pointer

> - Call an unsafe function or method

> - Access or modify a mutable static variable

> - Implement an unsafe trait

> - Access fields of unions

> It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa...

I’m not even sure that captures it. You must not void the safety contract in unsafe Rust. The distinction is that with unsafe, you must manually uphold the safety contract.

Ah yes, you’re right that I missed that part. The contract isn’t voided by using unsafe, what changes is that responsibility of enforcing the contract is moved to the developer instead of the compiler.

Once had a problem where customers complained about an app keep crashing and losing minutes or hours of work. Boiled down to a "null reference" in C++. Programmer responsible argued till blue in the face that his code could not have a bug because references (&) cannot be null. Of course they can.

Rust, at least, requires that this happens in unsafe code, but for sure, a bug in unsafe code can lead to null references. We are doing noobs a disservice if we claim otherwise.

> Programmer responsible argued till blue in the face that his code could not have a bug because references (&) cannot be null. Of course they can.

It's undefined behavior merely to create a null reference in C++, whether or not it's used. Of course that doesn't mean you can't do it anyway ("int * p = NULL; int &x = * p;") but the bug would be in the code that created the null reference, not the code that used it, just as in Rust the bug would be in the unsafe code which created the null reference—Safe Rust code is allowed to assume that this situation will never occur.

(One side effect of this rule is that the compiler is allowed to assume that "&x == NULL" will always be false for any reference "x", so even if you attempt to check for a null reference the check can be optimized out.)

It was his code the created the null reference. He converted a null pointer into a reference. But doesn't matter: when presented with the evidence of a null reference, it would have been straightforward to diagnose the problem. And after repeated blustering and denials from him, that's what I had to do to get the bug fixed. We do a disservice if we tell people that references (in either language) cannot be null. They can be null, and that would be a bug in some other code - so follow the trail to find where.

You can only dereference this pointer if you work at Google!

Wait, there are non-Googlers here? Who let them in?