Automatic invariant generation

[Steven Schveighoffer via Digitalmars-d]

On 7/9/17 7:45 AM, Nicholas Wilson wrote:
> On Sunday, 9 July 2017 at 11:37:55 UTC, Steven Schveighoffer wrote:
>> On 7/9/17 7:00 AM, Walter Bright wrote:
>>> On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
>>
>>>> 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!
>>>
>>> You're a few years late, as pretty much nobody agreed with me that 
>>> the operating system handling of it was plenty.
>>
>> I think you misunderstand, we have etc.linux.memoryerror that can 
>> actually throw an error on a null pointer using the signal handler.
>>
>> I have a suggestion: eliminate this feature, and add a -npe switch to 
>> the compiler that errors on any null pointer usage. Asserts will be 
>> sprinkled in everywhere, but may be useful to someone debugging a 
>> nasty null pointer segfault somewhere.
> 
> I think the generated assert(this !is null) has its place, it is useful 
> to catch a null this as early as possible but not by default. Perhaps 
> debug mode (as in the compiler switch) or a switch of its own.

I'd argue it's not useful at all. I've seen segfaults many many many 
times when debugging D code. I've never seen this error show up. Even 
when developing RedBlackTree (which is full of null pointers to structs 
on every leaf). And it makes sense why too:

1. Structs are generally allocated on the stack, or an array, or inside 
another type. Very rarely would you have a struct pointer that you 
didn't initialize (and was therefore null).
2. Often times, you are using a struct's data members, so you get a 
segfault before ever trying to call a method on it.
3. Classes are where you might see this issue, as people declare a class 
and try to use it without allocating one all the time. But in this case, 
when you are calling a virtual function, the segfault occurs before the 
assert can ever be used.

That being said, if people depend on it for some reason, switching it to 
an opt-in feature would be fine with me. In that case, I suggest just 
going whole-hog, and instrumenting all pointers.

-Steve