against enforce

[Jonathan M Davis]

On 2011-03-28 00:53, Don wrote:
> 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.

What's even more surprising is how invariants sometimes find bugs in _other_ 
code (e.g. http://d.puremagic.com/issues/show_bug.cgi?id=5500 ) instead of 
just the member functions of the type with the invariant.

- Jonathan M Davis