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