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
