Automatic invariant generation

[Nicholas Wilson via Digitalmars-d]

On Sunday, 9 July 2017 at 10:37:53 UTC, Steven Schveighoffer 
wrote:
> 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

In C++, but I recently ran across this problem debugging LLVM and 
wasted a good while trying to figure out what was causing the 
crash. This would have been a useful feature (actually if i had 
been comping in debug mode I would have hit that informative 
assert but I was too stubborn to recompile), so it does have its 
place but I think on by default is not it and certainly if it is 
not under my control.

The most annoying part is that the struct will _never_ be passed 
by pointer, its a struct that contains a struct that contains a 
pointer, POD if ever there was. In the older models of OpenCL you 
can't have pointers to pointers _at all_ so by definition the 
assert will never be triggered.