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.
