against enforce

[Don]

Jonathan M Davis wrote:
> On 2011-03-26 08:55, 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).
> 
> Whereas I _rarely_ use in contracts. In most cases, I favor exceptions, 
> treating my functions as API functions pretty much as long as they're public. 
> That's not always the best approach, but it's generally what I end up using.
> 
> invariants, I use fairly frequently (and in fact have run into trouble due to 
> issues with them - e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5058 ).
> 
> out, on the other hand, I don't use as much. It's not terribly common that 
> there's a good test to run on the return value of a function in my experience. 
> Upon occasion, it's useful, but rarely. Unit tests generally solve the problem 
> better with regards to testing output. They're still useful though - just not 
> commonly so.
> 
> So, honestly, other than invariants, I don't use D's DbC much. in contracts 
> get used upon occasion, but I tend to favor exceptions over assertions in most 
> cases, so I don't use in all that often, and while out is occasionally useful, 
> unit tests generally do a better job of verifying that a function's return 
> value is correct. I'm _very_ glad to have invariants though.
> 
> - Jonathan M Davis

If you only have standalone functions, at the moment there's not really 
any benefit to in and out contracts. You can equally well put the 
asserts at the start and end of the function.

I totally agree with you about invariants. I've been amazed at how many 
bugs can be caught by even a very trivial invariant.