Gavin Lambert wrote:
On 10/7/2013 11:47 PM, Quoth Julian Gonggrijp:
While I'm not Matt Calabrese, I think I can restate why it should be a precondition *especially* on the constructor. The entire point of the proposed non-null pointers is to guarantee that the pointer is not null, so that receiving functions and storing objects can assume that it is not null. If you zero-initialize a pointer whose very purpose is not to be null, you defeat the purpose of its existence.
This sounds to me like an argument *for* the position I am suggesting, not against it.
Throwing an exception means that the internal bare pointer is never initialised to null (or at least that if it is initialised to null, it can never be accessed as such because the resulting object is not retained), which means that it will never be accessed in an undefined way.
If you fail to throw the exception (and to assert, because you're in a release build) then you *do* go on to set the bare pointer to null, and *the program does not immediately fail*. By contrast, it will fail at some unknown later point at which someone actually attempts to access the pointer. If you're lucky, that's in the following line, and the bug is easier to find. If you're unlucky, it's three hours later (because the pointer was created as a member field in another object that is only accessed rarely) and it's much harder to figure out what happened.
Checking in the constructor is instant and failsafe. Not checking is just leaving a time bomb in the code.
[...]
I'm sorry to say this, but I think you're now just being evasive. A few posts ago in a reply to Matt, you stated that you agreed that if the assertion is to be replaced by a throw, the precondition should be removed from the constructor. This means that you also agree that if the precondition is *not* removed from the constructor, the assertion should *not* be replaced by a throw (modus tollens). You then argued that the precondition should indeed be removed because you find that the check is important enough to not remove it in release builds. You challenged Matt to give you a reason why the precondition should be preserved. Matt has explained why it should remain a precondition and I have restated in my own words why it should. My argument was not about whether the condition is important enough to check in a release build. I was stating why it should be a precondition. You did however not react to the content of my argument; instead, you coerced it into an argument on why the condition should be checked. You have not evaluated whether you agree that it should be a precondition. In this way we cannot make progress. Either you agree that the condition should be a precondition, or you don't but then you should join the discussion on what's the purpose of the non-null pointer and on what's the responsibility of the programmer. I don't think that anyone disagrees that in the ideal world, all conditions are always checked. Apparently we also agree that checks on preconditions should be assertions when a check is at all possible. So the discussion should be about whether not passing null to the constructor is a precondition. -Julian