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.
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
I think the objection is that small objects with non-virtual
member-functions and a path that does not dereference the
this-pointer will pass incorrectly if this is null.
Assume you add a non-nullable pointer type.
Then you probably would want to assume that the this pointer is
never null so that you don't have to test it manually before
assigning it to a non-nullable pointer variable. Or you risk
getting null into non-nullable pointers…
But it really depends on how strong you want the type system to
be.
