Thoughts about D

[Jonathan M Davis]

On Thursday, November 30, 2017 10:39:07 Ola Fosheim Grøstad via Digitalmars-
d wrote:
> On Thursday, 30 November 2017 at 09:01:20 UTC, Jonathan M Davis
>
> wrote:
> > It's close enough. Instead of segfaulting when the member
> > function is called, it'll segfault when it tries to access one
> > of the member variables or non-final member functions inside
> > the member function. So, there isn't any more need to add null
> > checks for final member functions than there is for non-final
> > member functions.
>
> Err... wait. What if you have a conditional:
>
>      if(input == 0) { do something bad }
>      access field
>
> Seems like you would be better off by injecting:
>
>     assert this not null
>
> at the beginning of all final methods and remove the assertion if
> all paths will lead to a field access before something bad can
> happen.
>
> Adding checks and then only remove them if they provably have no
> consequence tend to be the safer approach.

All we need to do is insert null checks before calling any member function
on an object that is large enough where segfaulting won't happen if the
reference or pointer is null. Whether the function is virtual or not really
doesn't matter, and there's no need to add checks if segfaults are going to
happen on null. That would mean that for large objects that have a path in a
non-virtual function that would not access any members, you'd end up with an
Error being thrown or a HLT being triggered (or whatever the compiler
inserted check did), whereas it would have squeaked by in a smaller object,
but it's really a bug to be calling a member function on a null object
anyway.

The key thing here is that we properly guaranteed @safe, and normally that
doesn't require null checks thanks to the CPU doing that for you and
segfaulting. It's just the overly large objects where that's not going to
work, and we can add null checks then - which hopefully the compiler can
optimize out in at least some cases, but even if it can't, that's just the
price of having that code be @safe; most code wouldn't be affected anyway,
since it only applies to particularly large objects.

- Jonathan M Davis