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

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sun Nov 19 00:34:55 UTC 2017


On Saturday, November 18, 2017 15:24:49 Timon Gehr via Digitalmars-d wrote:
> 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.

@safe as it stands provides a way to segregate code that potentially
introduces memory corruption and invalid memory accesses. Trying to add
anything related to null pointer dereferencing would just increase the
amount of code that would have to be @system, making it harder to deal with
problems actually related to memory corruption. And really, to avoid the
possibility of dereferencing null would require introducing non-nullable
pointers and references, because you're never going to be able to guarantee
it for nullable pointers or references, and honestly, I think that it would
destroy @safe to treat dereferencing nullable pointers or references as
@system. Too much code would be @system, making it far more difficult to
segregate code that dealt with actual, memory safety issues.

Perhaps there would be some value in having non-nullable pointers or
references, but they're an issue orthogonal to memory safety. And honestly,
I'm not even vaguely convinced that null pointers or references are much of
a real problem. Personally, pretty much the only time I run into problems
with them is when I forget to initialize a class reference. It's incredibly
rare that I end up with a program that ends up dereferencing null. And when
it does, you get a segfault and potentially a core dump, and the problem is
usually easy to fix.

Really, I don't think that dealing with potentially dereferencing null is
all that different from dealing with potentially dividing by zero. It sucks
when it happens, because it kills your program, but it's really not all that
hard to avoid. And at least when it does happen, it's obvious rather than
introducing subtle and hard to track down problems like you frequently get
with code that isn't memory safe.

- Jonathan M Davis



More information about the Digitalmars-d mailing list