Mind explaining why it's a bad thing to rely on the OS's built-in protections around nulls?

I'm familiar with a few arguments w.r.t. large structs and arrays running past the protected pages, but they seem pretty trivially solvable. Would love to hear why it's a cursed definition.

Well for one the code might be running in kernel space, so a null pointer access could very well be fatal. There are also use cases that D supports (e.g. certain bare metal arm targets) where the all-bits-zero pointer is validly addressable and contains Important Stuff.

Those protections are there as last ditch safety measures. You shouldn't rely on them .

Reasonable answers, thank you! I wonder how D might address that.

Exactly - the language isn't memory-safe. Instead it's effectively (implicitly!) relying on the fact that it runs on an abstract machine that has certain memory-safety properties. By contrast, a memory-safe language like C# is defined to be running on a memory-safe abstraction (the CLR, or more generally anything that faithfully implements the Microsoft intermediate language), while a memory-safe language like Rust either proves behaviour via the type system (no null pointers, no use after free) or inserts runtime checks (no out-of-bounds array accesses, panic on out-of-memory).

I'm not sure about D's situation specifically, but one issue with null ptr dereferences in C, C++, and (unsafe) Rust is that they're UB by definition, so you're at the mercy of the optimizer if it can ever prove that you're dereferencing null. This has led to some interesting security issues in the past: https://lwn.net/Articles/342330/

An optimiser may not treat null-dereferencing D code as undefined behaviour. It must either error at compile time (if it can prove the dereference would be null no matter what), crash at runtime, or derefer the null address, which also results in a crash.

Most definitions of memory safety include not crashing.

Nope. Memory safety means no undefined behaviour. Crashing is defined behaviour. Indeed, at least in the D philosophy it is better to crash than to just do something and continue when a bug is detected. If that were not the case, assertions in released code would be total humbug.

Now, detecting such errors statically at compile time is still valuable where it is practical. But it's common knowledge that no language guarantees no bugs. It follows that a complete "no crashing" guarantee is not even desirable, let alone part of a memory safety guarantee.

Having the program exit when a memory safety fault is detected is entirely safe.

What about bounds checking on array access, like most memory safe languages?