On Sunday, 18 August 2013 at 16:15:30 UTC, Borislav Kosharov wrote:
> On Saturday, 17 August 2013 at 17:48:04 UTC, Andrej Mitrovic wrote:
>> On 8/17/13, Borislav Kosharov <boby_dsm@abv.bg> wrote:
>>> I really think that this should be added to the language, because
>>> it doesn't break stuff and it is useful. And the 'static' keyword
>>> is already used in many places like module imports and ifs.
>>
>> Have you tried using the new getUnitTests trait in the git-head
>> version? If not it will be in the 2.064 release.
>>
>> Btw such a 'static unittest' feature is certainly going to break code
>> because static can be applied as a label, for example:
>>
>> class C
>> {
>> static:
>>    void foo() { }
>>
>>    unittest { /* Test the foo method. */ }   // suddenly evaluated at
>> compile-time
>> }
>
> Oh I really haven't tough about that. Maybe, I will try this new trait. Or another solution is to add a compiler switch that will try to execute all the tests during compilation or something.

Well, that assumes all your code is ctfe-able...

I've taken to doing something along the line of:

unittest
{
    void dg()
    {
        BODY OF UNITTEST
    }
    dg(); //test runtime
    assertCTFEable!dg; //test compiletime
}

It's a quick and easy way of testing both code paths, with minimal duplication and hassle.

On 8/5/2013 11:27 AM, monarch_dodra wrote:
> What about, for example:
>
> assertCTFEable!({
>      int i = 5;
>      string s;
>      while (i--)
>          s ~= 'a';
>      assert(s == "aaaaa");
> });

I don't believe that is a valid use case because the code being tested is not accessible from anything other than the test.

On Sunday, 18 August 2013 at 20:35:06 UTC, Walter Bright wrote:
> On 8/5/2013 11:27 AM, monarch_dodra wrote:
>> What about, for example:
>>
>> assertCTFEable!({
>>     int i = 5;
>>     string s;
>>     while (i--)
>>         s ~= 'a';
>>     assert(s == "aaaaa");
>> });
>
> I don't believe that is a valid use case because the code being tested is not accessible from anything other than the test.

I'm not sure what that means. Isn't that the case of all unittest?

In any case, I was just saying the above template was enough for our needs, and that I don't think a language solution is in order. Also, I think the:

//----
unittest
{
    void dg()
    {
        BODY OF UNITTEST
    }
    dg(); //test runtime
    assertCTFEable!dg; //test compiletime
}
//----

usecase makes it useful. Although arguably, you could just:

//----
unittest
{
    bool dg()
    {
        BODY OF UNITTEST
        return true;
    }
    dg(); //test runtime
    enum a = dg();
    or
    static assert(dg);
}
//----

But really, I'm just saying why type that when the template does it pretty well for us, while being self-docuenting?