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