against enforce

Don nospam at nospam.com
Sat Mar 26 08:55:53 PDT 2011


spir wrote:
> On 03/25/2011 11:20 PM, Jonathan M Davis wrote:
>> In the case of something like dividing by 0 or other math functions 
>> that could
>> be given bad values, the typical solution is to either use an 
>> assertion (or
>> check nothing) and then let the caller worry about it. It would be 
>> extremely
>> wasteful to have to constantly check whether the arguments to typical 
>> math
>> functions are valid. They almost always are, and those types of functions
>> needto be really efficient.
> 
> But catching wrong arguments to math functions at *runtime* is precisely 
> what D itself does (as well as all languages I know):
> 
>     auto a = 1, b = 0;
>     auto c = a/b;
> ==>
>     Floating point exception
> 
> There is no way out, or do I miss a point?
> 
> Denis

That one is done by the CPU, as mentioned in another post. But it does 
illustrate something interesting: the contract programming makes you 
think there is a symmetry between in and out contracts, whereas in fact 
they have very little in common. If an out contract fails, it ALWAYS 
indicates a bug in the function. So it should ALWAYS be an assert.
But 'in' contracts are completely different, since they indicate a 
problem in the calling code. (Personally I cannot see the value of 'out' 
contracts, except as information for verifying later 'in' contracts).

When I started writing D code, I originally used 'in' contracts 
frequently in my mathematical code. But later, I removed most of them. 
Why? Because including a particular condition in a 'in' contract makes 
it undefined behaviour in release mode!

So you need to be clear, is this parameter value a runtime error, or is 
it a bug in the calling code?
In most mathematical code, you want it to be an error -- you don't 
normally want undefined behaviour for particular inputs. If the 
requirements for valid parameter values are complicated, you're placing 
a huge burden on the caller if you include asserts, making them bugs.

In summary: enforce is nice for the caller, assert is nice for the callee.

The decision of whom to favour can be tricky.


More information about the Digitalmars-d mailing list