On Monday 03 January 2011 01:38:29 Vladimir Panteleev wrote: > On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > So, please have a look at the code. > > Just one thing: wouldn't these functions also be useful in contract > programming (invariants etc.)? Perhaps they should just be added to > std.exception?
Well, they're written with unit tests in mind rather than contracts. Unit tests and contracts have similar but different purposes. I wouldn't really want to conflate the two. Also, it's std.exception now rather than std.contracts specifically because it doesn't really relate to contracts, so even if you did want to use unit testing functions in contracts, I'm not sure that std.exception is the right place to put such functions anyway. As it stands, the entire module is in a version(unittest) block, so the functions can't be used outside of unit tests. If a lot of people really thought that unit testing functions would be useful and reasonable to use inside of contracts, then it would make some sense for the unit testing functions to no longer be in a version(unittest) block. But personally, I'd be a bit worried to see more than simple assertions inside of contracts. Contracts should be efficient, since they're going to be run while the code is running normally, whereas unit tests don't have to worry about efficiency quite as much. I believe that the functions that I have are efficient, but I can easily see functions intended to aid in unit testing being totally inappropriate in a contract due to efficiency concerns. And of course, a number of the unit testing functions just don't make sense in contracts regardless - like assertExThrown. Howevr, regardless of whether the functions are deemed reasonable for use in contracts, I do think that having a module of functions designed specifically for use in unit tests is of definite value, and regardless of the current size of the module, it's quite possible that it could become fairly large at some point if enough useful unit testing functions are devised. Merging that in with std.exception seems ill-advised to me. Not to mention, it's a lot more obvious that you're dealing with functions intended to aid in unit tests when the module is named std.unittests than if those functions are lumped in with the stuff in std.exception. - Jonathan M Davis