"Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 4/14/11 12:00 PM, Steven Schveighoffer wrote:
>> On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> 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