Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....

[John Carter]

On Tuesday, 3 July 2018 at 04:54:46 UTC, Walter Bright wrote:
> On 7/2/2018 7:53 PM, John Carter wrote:
>>> In general all pre/post/assert-condition violations) cause a 
>>> corrupted state that cannot be recovered from 
>>> programmatically, and so they should never be reported to the 
>>> calling code as exceptions or error codes that code could 
>>> somehow handle.
>> 
>> Ah, that's a really nice statement.
>
> So, I have finally convinced the C++ world about that! Now if I 
> can only convince the D world :-)

Oh, I'm convinced.

At work here I have emerged from a long, dark, debate on the 
subject within the team.

The ultimately solution was to realize there are actually TWO 
facilities with TWO entirely different purposes that have been 
overloaded with the same name.

Alas, the word "assert" now is inextricably mired in this 
confusion.

Half our team used asserts to mean "This mustn't _ever_ happen in 
unit tests (unless we set up a specific test case for that), and 
it will never happen if the incoming signal is standards 
compliant, but it may happen (due to RF noise, and/or competitor 
violating the standard and/or adding in proprietary stuff into 
the data and/or we're being attacked) so we _must_ fall through 
the assert at run time, and handle that case somehow, but 
preferably make a note that something unexpected happened."

The other half of the team meant, "If the expression is false, it 
means the code on this line or on the execution path prior to it 
is definitely defective and must be fixed immediately.

And there is absolutely no hope the code after it will work, and 
continuing on will make the system flaky and unreliable, and the 
only path back to reliable function is a reset.

All code after this line may explicitly assume, and depend on, the
expression being true.

Any attempt to handle the possibility of the expression is false 
is buggy, useless and probably will be removed by the optimizer.

Any urge to handle the possibility of the expression being false 
after the assert, should be replaced by the inclination to review 
the code on the execution path prior to the assert, to ensure 
that the expression will always be true."

Alas, both sides were using the same word "assert" to mean these 
different things, resulting in conversations that went around and 
around in meaningless circles.

We have resolved the debate by identifying these two different 
meanings, and given the facilities implementing them two 
different names and documenting the difference in meaning and 
intent.