std.unittests for (final?) review

[Nick Sabalausky]

"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 would cover any typical use-case, and I suspect anything that 
doesn't cover would probably be overly-complex anyway and should be 
re-written.

Or, like I suggested in another branch, use some form of markup to denote 
what should be printed. Example:

assertPred!`#foo()# < #bar()# && #hello()# < #world()#`();
assertPred!`{foo()} < {bar()} && {hello()} < {world()}`();
// Etc, whatever...

That would probably need to return a string intended to be mixed in, which 
might be unappealing, but frankly we need a better way to instantiate string 
mixins anyway. I get real tired of library writers being made to feel 
pressure to avoid the power of string mixins just because they're 
(admittedly) ugly to use.