On Wednesday 05 January 2011 23:08:21 Nick Sabalausky wrote: > "Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message > news:mailman.446.1294293885.4748.digitalmar...@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
