alwaysAssert() [was: Against enforce()]

[Andrei Alexandrescu]

On 03/17/2011 06:12 PM, Walter Bright wrote:
> On 3/17/2011 3:08 PM, Andrei Alexandrescu wrote:
>>> if (!condition) { writeln("my message %s %s", __FILE__, __LINE__);
>>> assert(0); }
>>>
>>> I am strongly opposed to using enforce() for bug detection.
>>
>> There's nothing wrong with encapsulating this idiom (if frequent).
>> That's what
>> essentially alwaysAssert does. So you're right but without contradicting
>> dsimcha's suggestion.
>
> Sure, but there is plenty wrong with using enforce() for bug detection
> even if alwaysAssert does not exist. For one thing, such uses encourage
> others to misunderstand and misuse enforce.

(I'm not sure what you even want to convey here as your statement does 
not contradict or oppose any other, yet is grammatically formulated as 
if it did. One may as well reply with "Yes, but the water's wet.")

No question enforce would be wrong for bug detection. Using this would 
be just as wrong:

if (undefinedState) throw new Exception("Hmm, odd...");

By packaging the if/throw combo, enforce becomes a notion, a part of the 
vocabulary, a meme if you wish. That makes it neither more nor less 
wrong for bug detection, but makes it plenty better for systematic error 
handling.

Now, there is an additional issue that may confuse people on the 
relative roles of assert and enforce. We have faced the question, how do 
we validate arguments to a function in Phobos?

Initially I used enforce() all over the place, under the assumption that 
Phobos' user and Phobos are separate entities. Therefore, any argument 
coming from outside Phobos would be necessarily considered I/O from 
within Phobos and therefore scrubbed accordingly.

Then there was pressure on loss of efficiency due to checking, so I and 
others replaced certain instances of enforce() with assert(). This is 
not wrong at all. Instead, it reflects a different view of the dynamics 
between Phobos and its user: now Phobos + user code is considered as an 
entity that works together. So a failing assert in Phobos could describe 
a bug in Phobos itself or one in the application code that uses it. This 
is more ambiguous but not one bit less correct under the stated assumptions.

> Additionally, alwaysAssert is an obvious one liner. I think such things
> need to be very frequently used to consider them part of the standard
> library. Otherwise, we risk Phobos becoming a morass of trivia.

enforce() is an obvious one liner too. Size is not the only means to 
assess the usefulness of an abstraction. Two others are frequency of the 
pattern (think "writeln") and ascribing a meaningful name to it (think 
"unittest").

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-12.html#%_sec_1.3 
is a good read, let me paste:

=========================
We have seen that procedures are, in effect, abstractions that describe 
compound operations on numbers independent of the particular numbers. 
For example, when we

(define (cube x) (* x x x))

we are not talking about the cube of a particular number, but rather 
about a method for obtaining the cube of any number. Of course we could 
get along without ever defining this procedure, by always writing 
expressions such as

(* 3 3 3)
(* x x x)
(* y y y)

and never mentioning cube explicitly. This would place us at a serious 
disadvantage, forcing us to work always at the level of the particular 
operations that happen to be primitives in the language (multiplication, 
in this case) rather than in terms of higher-level operations. Our 
programs would be able to compute cubes, but our language would lack the 
ability to express the concept of cubing. One of the things we should 
demand from a powerful programming language is the ability to build 
abstractions by assigning names to common patterns and then to work in 
terms of the abstractions directly. Procedures provide this ability. 
This is why all but the most primitive programming languages include 
mechanisms for defining procedures.
=========================


Andrei