Invariant and pre/post-conditions order

[Walter Bright]

On 1/19/2012 8:19 PM, Steven Schveighoffer wrote:
> If they are related, yes it does give you more information. The out condition
> might not check the class data directly, but the error which caused the
> invariant to fail could have also caused the out-condition to fail. It's
> inconsequential to the *program* whether the out condition or the invariant
> halts execution. But to the developer receiving the assert message, it's much
> more helpful to see an out condition failing than an invariant. If they are
> related, and caused by the same bug, it's that much more helpful.

I utterly fail to understand your argument about it being more helpful.


> Imagine you
> have 1000 lines of code that call 50 or so different methods on a class. Any one
> of those calls in any one of those methods could cause an invariant failure. But
> only one method call can cause a specific out condition failure, and the lines
> of code that call that function might be significantly less than 1000 (maybe a
> handful).

This does not make sense to me. If a bug would cause an invariant failure and an 
out failure, and one is run right after the other, there is zero advantage to 
one being run before the other.

    assert(s);
    assert(s);

which one should be run first?

> With almost no change to execution speed, semantics, or pretty much anything,
> you will have saved the developer minutes to hours (under the right
> circumstances, maybe even days or weeks) of crappy "how the hell do I find this
> bug" time.

I see no advantage, even to your hypothetical. I think you would be *very* hard 
pressed to come up with an example.

 > I can't see a single drawback aside from the time it takes to test
 > the changes to the compiler.

Changing the language requires more than no drawbacks, it requires a compelling 
demonstration of value added.

> even your second reason is flawed -- in order for there to be a noticeable
> difference, one would have to make their invariant actually *change* the object.
> Why do we support that? In fact, this change would help them discover their
> flawed invariant code :)

Invariants and conditions are allowed to be impure so they can do things like 
logging.