Introducing Nullable Reference Types in C#. Is there hope for D, too?

Timon Gehr timon.gehr at gmx.ch
Sat Nov 18 14:24:49 UTC 2017


On 17.11.2017 15:53, Jonathan M Davis wrote:
> 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.

The current discussion is about how safety *should* be viewed in D in 
the future, as in, potentially /changing/ how it is viewed. This means 
rehashing the status quo without giving justification for it is not 
useful. Why *should* @safe only mean "does not corrupt memory" or 
"accesses memory that it should not access"? Why can't it also mean 
"does not attempt to dereference null pointers"? Note that it is up to 
the language to _define_ what @safe does and does not mean. If the 
language evolves, that meaning may evolve too.


More information about the Digitalmars-d mailing list