Automatic invariant generation

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 9 03:37:53 PDT 2017


On 7/9/17 5:14 AM, Walter Bright wrote:
> On 7/7/2017 7:31 AM, Nicholas Wilson wrote:
>> asserts that the this pointer is not null, apparently which is 
>> annoying because you'd crash anyway. I suppose you might get a nicer 
>> error message but it doesn't add much.
> 
> If I recall correctly, the nicer message was the reason. (It was a long 
> time ago.)
> 
> This kind of thing has been asked for, a lot. The current thread entitled:
> 
> "All asserts need to have messages attached! Explicit as possible!"
> 
> is representative.

Wait, you have stated many many times, a segfault is good enough, it's 
not worth the added cost to do null pointer exceptions (a position I'm 
completely in agreement with). Yet, here is an example of where we have 
effectively added a null pointer exception. At the very least, this 
should be eliminated on Linux and just use the signal handling null 
pointer error mechanism!

Note that there is a significant difference between this situation 
(where you are *adding* an extra check), and the argument to add 
messages to asserts (where you are *already* asserting). For the record, 
I also don't agree that all asserts need messages.

Also noted, even if you inline, the assert is still there. Those who 
want to keep asserts (particularly for safety reasons), will pay this 
penalty.

In things like smart pointer wrappers or converters, many things are 
properties. inlining these is supposed to boil down to simply accessing 
the right field, with zero added cost. That is also a lie.

Or factoring out pieces of a function into more modular member 
functions. Now you are compounding the asserts. When calling another 
member function from within one, there is no reason to re-assert `this 
!is null`.

We need to get rid of this feature, or at least make it optional (and by 
optional, I mean opt-in). And no, having -release remove all asserts is 
not the same as having the ability to eliminate asserts I never wrote or 
wanted. At least the assert shouldn't appear in virtual functions (which 
will never fail because the vlookup will segfault before it ever gets 
there).

I've been using D for 10 years, and have never triggered this assert. 
But I've apparently paid for it that entire time.

-Steve


More information about the Digitalmars-d mailing list