Andrei's Google Talk

[Norbert Nemec]

On 03/08/10 22:56, Walter Bright wrote:
> bearophile wrote:
>> 27.50, "transactional file copy": this example was script-like, and as
>> short
>> as possible to fit into one single slide, so in this case I think using
>> enforce() is OK. But in true programs I suggest all D programmers to use
>> DesignByContract with assert() more and to use enforce() less. Among
>> other
>> things enforce() kills inlining possibilities and inflates code. In
>> D.learn I
>> have seen people use enforce() in a situation where DbC is designed
>> for. I
>> think the D community needs to learn a bit more DbC, and in my opinion
>> to do
>> this the leaders have to lead the way.
>
> There's a misunderstanding here. Contract programming is for detecting
> program bugs. enforce() is for detecting and handling errors such as
> disk failures and bad user input.
>
> They are COMPLETELY DIFFERENT and must not be conflated.
>
> (For example, assert() goes away when compiled with the -release switch.
> enforce() does not.)

I agree. Still, I agree with bearophile that 'enforce' should be 
avoided. It is a quick-and-dirty solution for situations where a proper 
exception should be issued. Essentially, an 'enforce' violation says 
"Something went wrong!" without giving a clue about the real problem. 
That's OK in the development phase but should be replaced when the code 
matures.

And as for the concept of "user input" vs. "contracts": A library 
interface is *not* a user interface. After some consideration, I agree 
that a library should always check its input even in "release" mode. 
However - this should be solved by selectively toggling contract 
checking rather than replacing contracts by "enforce" statements.