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

[H. S. Teoh]

On Thu, Jul 05, 2018 at 10:05:44PM +0000, John Carter via Digitalmars-d wrote:
[...]
> 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.
[...]

In D, I believe the first meaning is assigned to "enforce" (i.e.,
std.exception.enforce), and the second meaning is assigned to "assert"
(the built-in assert).

Unfortunately, the word "assert" has been used outside the context of D
to mean either thing, so people keep tripping over the terminology and
using assert for the wrong thing.  And it doesn't help that "enforce" is
a library function rather than a built-in construct, which some people
wrongly interpret as "secondary, therefore somehow inferior, and
probably not what I intend".


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr