std.unittests for (final?) review

[Jonathan M Davis]

On Wednesday 05 January 2011 19:35:13 Michel Fortin wrote:
> I'm not sold on the concept. The whole point of this module seems to
> offer a way to replace the built-in assertion mechanism with a
> customized one, with the sole purpose of giving better error messages.
> So we're basically encouraging the use of:
> 
> 	assertPredicate!"a > b"(a, b, "message");
> 
> instead of:
> 
> 	assert(a > b, "message");
> 
> It looks like an uglification of the language to me.
> 
> I agree that getting better error messages is important (very important
> in fact), but keeping the code clean is important too. If the built-in
> assert doesn't give us good enough error messages, perhaps it's the
> built-in assert that should be improved. The compiler could give the
> values on both side of the operator to the assertion handler, which
> would in turn print values and operator as part of the error message.
> 
> So to me this module is a temporary fix until the compiler is capable
> of giving the necessary information to the assertion handler. I sure
> hope it won't be needed for too long.
> 
> (Note: this criticism doesn't apply to those assertions dealing with
> exceptions.)

Well, I'm not about to claim that assert can't be fixed to give better error 
messages, but right now all it takes is a value which converts to bool for the 
test. a > b may obviously be convertible to something similar to 
assertPred!">"(a, b), but what about something like 1 + 1 < b or a < b < c. As 
expressions get progressively more complicated, it very quickly becomes non-
obvious what someone would really want to print on error. Would 1 + 1 < b print 
2 and b's value? Would it print 1, 1, and b's value? 1, 1, 2, and b's value? 
Sure, it may be obvious to the programmer what they intended, but it doesn't 
take much for it to be very difficult for the compiler to figure it out for you.

Also, assertPred!">"(a, b) would print out a more informative error message on 
its own. You wouldn't need to give it an additional message for it to be more 
informative. That would defeat the point. Even assertPred!"a > b"(a, b) could be 
more informative (assuming that it treats a > b as a general predicate rather 
than determining that it's actually >) by printing the values that it's given. 
So, that's definitely a leg up on assert(a > b) right there.

By passing each of the values to assertPred, we're able to print them out on 
failure without the computer having to understand what the predicate does, even 
when the values are arbitrary expressions. That would be very hard to do with an 
improved assert which just took the expression. I mean, try and write a function 
that took 1 + 1 > b or a < b < c as a string and tried to correctly print out 
values which are meaningful to the programmer. That would be _really_ hard. And 
while assertPred may not be able to understand a generic predicate, it can know 
about specific operators and/or functions and therefore give more informative 
error messages than it would be able to do with a generic predicate.

So, correctly implemented, I think that assertPred actually makes a lot more 
sense than trying to soup up assert and getting the compiler to guess at what 
the programmer really wants.

- Jonathan M Davis