Automatic invariant generation

[Jonathan M Davis via Digitalmars-d]

On Sunday, July 9, 2017 4:00:33 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
> > 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).
>
> That's right.
>
> > 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.

What I don't understand about this is that it's not like we have these sort
of checks in general - just in this weirdly specific case. I could
understand that argument if we were doing null pointer checks in general,
but we're not, and you clearly haven't given in to the push for that.

In _C++_, I have literally only seen a null this pointer inside a member
function twice in my career (and the second time it happened, I had to
explain what was happening to my coworkers - some of them being quite
knowledgeable - because they didn't even think that it was possible to call
a function with a null pointer and not have it blow up at the call site). I
have never seen this problem in D. I would be _very_ surprised if you
couldn't just remove this check, and no one would complain because they hit
this problem and didn't get an assertion.

> > 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).
>
> It's not really different. It's the desire for ever more messages. I've
> long advocated that a file/line is quite sufficient, but I seem to be in
> a tiny minority of 1. Now 2. :-)

For some assertions, having more than a file and line number is nice (e.g.
if you have messages for your pre-condition assertions, then you can make it
so that when it fails, the programmer doesn't even need to look at the
source code), but for many, many assertions, having a message doesn't do
much for you IMHO. You need to look at the code anyway, and if it's
asserting an internal thing rather than DbC, then it's usually really not
the sort of thing where a message is going to help particularly. In such
cases, the only real benefit that I see from having an error message that
does more than tell you where the assertion was and what the call stack was
is that if you have a message, and there are several assertions in the same
area of code, then when an assertion fails, you're less likely to mistake
one assertion for another if the source you're looking at doesn't exactly
match the build that the person reporting the issue was using (and that
mismatch isn't always obvious if you're not just building and running your
code locally).

So, to an extent at least, I agree with you, but a number of folks do seem
to think that messages that add no information are better than no messages
for some reason, and unfortunately, there's now a PR to outright require
messages for all assertions in Phbos:

https://github.com/dlang/phobos/pull/5578

- Jonathan M Davis