toHash => pure, nothrow, const, @safe

[H. S. Teoh]

On Mon, Mar 12, 2012 at 02:10:23PM -0400, Jonathan M Davis wrote:
> On Monday, March 12, 2012 11:04:54 H. S. Teoh wrote:
> > Tangential note: writing unit tests may be tedious, but D's inline
> > unittest syntax has alleviated a large part of that tedium. So much so
> > that I find myself writing as much code in unittests as real code.
> > Which is a good thing, because in the past I'd always been too lazy to
> > write any unittests at all.
> 
> D doesn't make writing unit tests easy, since there's an intrinsic
> amount of effort required to write them, just like there is with any
> code, but it takes away all of the extraneous effort in having to set
> up a unit test framework and the like. And by removing pretty much
> anything from the effort which is not actually required, it makes
> writing unit testing about as easy as it can be.

I would argue that D *does* make unit tests easier to write, in that you
can write them in straight D code inline (as opposed to some testing
frameworks that require external stuff like Expect, Python, intermixed
with native code), so you don't need to put what you're writing on hold
while you go off and write unittests. You can just insert a unittest
block after the function/class/etc immediately while the code is still
fresh in your mind. I often find myself writing unittests simultaneously
with real code, since while writing the code I see a possible boundary
condition to test for, and immediately put that in a unittest to ensure
I don't forget about it later.  This improves the quality of both the
code and the unittests.


> I believe that Walter likes to say that it takes away your excuse
> _not_ to write them because of how easy it is to write unit tests in
> D.
[...]

Yep.  They're so easy to write in D that I'd be embarrassed to *not*
write them.


T

-- 
Famous last words: I *think* this will work...