Thoughts about D

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu Nov 30 19:29:48 UTC 2017


On Thursday, November 30, 2017 19:14:50 Ola Fosheim Grøstad via Digitalmars-
d wrote:
> On Thursday, 30 November 2017 at 18:10:01 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> Well, it is a bug, but the member-function may have been written
> with an invariant in mind, so it would then go undetected on a
> small object and continue running with broken invariants (state
> outside the object).
>
> So without such a check there would be reduced value in builds
> with contracts. E.g. there could be a global involved that now
> has a broken invariant. Maybe contracts aren't really a major
> feature anyway, but such gotchas should be listed in the spec at
> least.

If there's an invariant, it's going to segfault as soon as it accesses any
member variables, and actually, it wouldn't surprise me if the invariant
were virtual given that I would expect a base class invariant to be run in a
derived class. And if the invariant is virtual, then you'll get a segfault
when it's called on a null reference even if the function itself isn't
virtual. In the case of pointers to structs, the invariant definitely
wouldn't be virtual, and the invariant would be executed, but it would
segfault as soon as it accessed a member.

Ultimately, I think that the main concern here is ensuring that @safe code
is actually @safe. As long it segfaults (or HLTs or whatever if an explicit
check is added) when it tries to use a null pointer, I don't think that it
really matters much whether it fails at the call point of the member
function or when accessing a member inside, and in my experience, having a
member function that doesn't use member variables is so rare as to be pretty
much a non-issue. Sure, having a code path that shortcuts things under some
set of circumstances and returns rather than accessing any members does
increase how often it happens, but arguably in that case, it also didn't
matter that the pointer/reference was null, since the object itself wasn't
actually needed.

- Jonathan M Davis




More information about the Digitalmars-d mailing list