On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 4/14/11 12:00 PM, Steven Schveighoffer wrote:
On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 4/14/11 9:03 AM, Steven Schveighoffer wrote:
Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code
is
compiling (this is especially true when I'm doing version statements
or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with
that
switch, of course).
Could this be achieved within the language?
I think you need to do it at the compiler level to make it useful. For
example, an assert like:
assert(container.length == 5);
To print this out properly, I'd want to see that the assert passed, but
also what the test was.
What's needed here is a "text of expression" feature similar to C's "#".
That would help enforce and other artifacts too. I'm thinking along the
lines of:
void myassert(string expr = __traits(text, condition))(bool condition) {
...
}
with, of course, a simpler syntax.
It still isn't exactly right. Assert has some special properties that
cannot be duplicated exactly with library code. Such as true lazy
evaluation and elimination during release mode.
But yes, it would be nice to be able to get a string of the parameters of
a function (macro?). It would certainly make this more feasible.
However, all this is ignoring one simple thing -- the hundreds of
thousands of lines of code (mostly from std.datetime ;) ) that already
have asserts. Hooking assert directly automatically gives us a tool for
printf debugging without changing any code.
I would point out that even for this solution, we are still modifying the
compiler. Any particular reason why adding a new trait is more desirable
than modifying assert? I certainly feel that the auto-inclusion of all
the existing asserts would far outweigh the extensibility of adding a
trait (which could probably also be added at the same time).
I think this would be an awesome feature. One of the cool things about
the new way phobos runs unit tests (one module at a time) is that if a
particular test fails, I can just build/run it over and over again until
it passes. This is huge since to run the full phobos unit tests can take
a while.
That's exactly how Phobos unittest work on Linux, and that was the
motivation behind making it work that way.
Yeah, I know, that's why I brought it up :)
-Steve
