against enforce

[spir]

On 03/26/2011 04:55 PM, Don wrote:
> 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.

Very interesting points of view, than you! Especially
* making the misleading symmetry between 'in' & 'out' contracts (==> importance 
of *naming*, again!)
* the relative weakness of in contracts or asserts.

About 'out' contracts, I know see them as an alternate way of testing, during 
development or maintenance. Kinds of constant assertions (in the logical sense) 
checked there, which may help catching bugs, and before all do not need to be 
checked in unittests.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com