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