std.unittests for (final?) review

[Jonathan M Davis]

On Wednesday 05 January 2011 23:08:21 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.446.1294293885.4748.digitalmars-d at puremagic.com...
> 
> > What about something like a < b && c < d? If assertPred!() takes more
> > than two parameters (as I would hope it would), then you could do
> > something like
> > assertPred!((a, b, c, d){return a < b && c < d;})(foo(), bar(), hello(),
> > world()) and it could not only tell you that the predicate failed, but it
> > could
> > tell you that the values that it was given were 1, 5, 4, and 2. How could
> > assert(foo() < bar() && hello() < world()) do that? It has to know where
> > to stop
> > the expressions evaluation to print it.
> 
> How about this set of rules?:
> 
> As the compler evaluates the assert's expression tree starting from the
> root:
> 
> 1. Literals DO NOT have their values printed.
> 2. Built-in-operator expressions (arithmetic, parens, comparison, etc) DO
> NOT have their values printed, but the compiler traverses their immediate
> sub-expressions.
> 3. Variables DO have their values printed.
> 4. Things that take parameters (such as a function call or an eponymous
> template instantiation) DO have their values printed, but the compiler does
> *not* traverse the parameters (unless this is the root-level expression).

I think that that you'd have to give some examples for it to be clear what 
exactly you mean, but it sounds like this would print a lot more values than 
would be desirable in complex expressions. With assertPred, I could do something 
like

assertPred!"=="(foo(bar(g, none("abc")) * 2, hello(world(i)) + 2 * func(funky(2 
+ q)), 25)

and get what the actual result was. e.g. "== failed: 14 != 25". I wouldn't want 
all of those arguments printed. It's the final result that matters. If I 
understand what you're suggesting, a lot of those arguments would be printed in 
your suggestion, which would be less than desirable, I think. Granted, that 
particular example is quite ugly, but I'd like to be able to test arbitrarily 
complex functions and still get a reasonably informative error when the test 
fails.

- Jonathan M Davis