against enforce

Alix Pexton alix.DOT.pexton at gmail.DOT.com
Fri Mar 25 03:44:22 PDT 2011


On 25/03/2011 08:04, Kagamin wrote:
>> So, there really is no good answer.
>> - Jonathan M Davis
>
> So why do you need to differentiate between assert and enforce if you can't choose, which of them should be used?
>
> We can't really turn off both of them, and if we really want performance and no checks, we would want to turn off both of them, so they should work in the same way, shouldn't they?

I can't think of an occasion when I would want to have my uses of 
enforce() stripped for a release build. Removing asserts once I am sure 
that my code has no logic errors make sense, but removing the code that 
validates user input and system integrity doesn't.

Performance is irrelevant if you are processing corrupted memory or 
malformed input.

Before there we had enforce, I did tend to use assert for both cases as 
I cobbled code together, then rewrite the validation parts as throws on 
the second pass. When enforce appeared that 2 phase process got much 
easier, and now I can choose the right one as I code, which increases 
productivity.

Enforce does not replace assert, it compliments it, and very elegantly so.

<aside>

With regard to libraries, there is an overlap between what is input 
validation and what is logic checking (a logic error in the code of 
program a, results in bad input being sent to lib b). Here, assert is 
the only choice as hitting an assert in a library (hopefully) exposes 
logic errors in the program that uses the library, this is something 
that you fix by reviewing your code, not by recovering at runtime and 
trying again. This means that libraries (should) have 2 types of assert, 
but I hesitate to suggest the creation of a synonym to help better 
document the difference between them, as I find that the use of in{} and 
out{} do a pretty good job of that already.

The only problems that I foresee are for libraries where the source is 
not available (which I have not had an issue with yet) and libs that 
wrap non-D code that does not use the same conventions. In these cases, 
one will not always know if the -release flag (or equivalent) has been 
used. If it has, then one may not find logic errors as one codes, if it 
hasn't then one will find the errors, but will not be able to strip the 
asserts when producing one's own release build.

</aside>

A...


More information about the Digitalmars-d mailing list