On Friday, November 17, 2017 15:05:48 Timon Gehr via Digitalmars-d wrote: > On 17.11.2017 12:22, Jonathan M Davis wrote: > > On Friday, November 17, 2017 09:44:01 rumbu via Digitalmars-d wrote: > >> I know your aversion towards C#, but this not about C#, it's > >> about safety. And safety is one of the D taglines. > > > > Completely aside from whether having the compile-time checks would be > > good or not, I would point out that this isn't actually a memory safety > > issue. > Memory safety is not the only kind of safety. Also, memory safety is > usually formalized as (type) preservation which basically says that > every memory location actually contains a value of the correct type. > Hence, as soon as you have non-nullable pointers in the type system, > this _becomes_ a memory safety issue.
This is definitely not how it is viewed in D. Walter has repeatedly stated that dereferencing a null pointer is considered @safe, because doing so will not corrupt memory or access memory that it should not access - and that's all that @safe cares about. Whether there's an object of the correct type at that location or not is irrelevant, because it's null. You do have a memory safety issue if you somehow make the pointer or reference refer to an object of a different type than the reference or pointer is allowed to point to, but doing that requires getting around the type system via casting, which would not be allowed in @safe code, and badly written @trusted code can always screw up @safe code. Regardless, given that dereferencing null will segfault, it does not present an @safety problem. The only issue with dereferencing a null pointer in @safe code is that if the type is sufficiently large (larger than a page of memory IIRC), you don't actually get a segfault, and that hole does need to be plugged by having the compiler add runtime checks where needed. But most null pointers/references do not have that problem. - Jonathan M Davis
