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 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.

Well, while it might be nice if the mixin syntax was less verbose, I think that 
the markup suggestion is pretty ugly even if it mixed itself in exactly as you 
wrote it. I find the idea of passing the individual values in separating to be 
far more palatable. That does seem to be a matter of taste however.

- Jonathan M Davis