Are compile-time unittests possible in D? Maybe something like:

static unittest {
    assert(2 == 1 + 1);
}

So that every assert in the unittest is translated to static assert. And no normal asserts to be allowed in static unittest?
So the above code would be executed at compile time and translated to:

unittest {
    static assert(2 == 1 + 1);
}

On Monday, 5 August 2013 at 12:25:36 UTC, Bosak wrote:
> Are compile-time unittests possible in D? Maybe something like:
>
> static unittest {
>     assert(2 == 1 + 1);
> }
>
> So that every assert in the unittest is translated to static assert. And no normal asserts to be allowed in static unittest?
> So the above code would be executed at compile time and translated to:
>
> unittest {
>     static assert(2 == 1 + 1);
> }

Not right now at the very least. Use case?

On Monday, 5 August 2013 at 12:25:36 UTC, Bosak wrote:
> Are compile-time unittests possible in D? Maybe something like:
>
> static unittest {
>     assert(2 == 1 + 1);
> }
>
> So that every assert in the unittest is translated to static assert. And no normal asserts to be allowed in static unittest?
> So the above code would be executed at compile time and translated to:
>
> unittest {
>     static assert(2 == 1 + 1);
> }

Not exactly as you describe but you can do unit tests for CTFE functions. Have a look at this thread:

http://forum.dlang.org/thread/ks1brj$1l6c$1@digitalmars.com

--
/Jacob Carlborg

On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:
> Use case?

The use case is simply checking that your functions can be CTFE'd, and that they produce the correct result.

> Not right now at the very least.

std.exception defines the package "assertCTFEable".

It allows code such as:
unittest
{
    assertCTFEable!(
    {
        assert(to!string(1uL << 62) == "4611686018427387904");
        assert(to!string(0x100000000) == "4294967296");
        assert(to!string(-138L) == "-138");
    });
}

If this code does not run at CTFE, then a static assert triggers.

This is currently "package", but it proves that what you asked for is not only possible, it is implemented *and* used in phobos.

So either duplicate locally, or file an ER to make it public I guess.

On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
> On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:
>> Use case?
>
> The use case is simply checking that your functions can be CTFE'd, and that they produce the correct result.

Considering your, example, you can always do `static assert(to!string(1uL << 62) == "4611686018427387904");`

What is the crucial difference?

On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
> This is currently "package", but it proves that what you asked for is not only possible, it is implemented *and* used in phobos.

topic-starter has been asking about _language_ feature and my answer was related to this possible _language_ feature. Existence of some template in Phobos does not prove anything here.

On Monday, 5 August 2013 at 17:13:52 UTC, Dicebot wrote:
> On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
>> On Monday, 5 August 2013 at 14:02:06 UTC, Dicebot wrote:
>>> Use case?
>>
>> The use case is simply checking that your functions can be CTFE'd, and that they produce the correct result.
>
> Considering your, example, you can always do `static assert(to!string(1uL << 62) == "4611686018427387904");`
>
> What is the crucial difference?

Well, the "crucial" difference is that this tests a single expression, and not an entire block. For example, the simple test that int.init is 0:

static assert({int i; assert(i == 0;});

This doesn't work. You'd have to write:
static assert({int i; assert(i == 0; return 1;}());
or
static assert({int i; assert(i == 0);}(), 1);

Both of which are a bit combersome. "assertCTFEable" allows testing that the *block* will actually will compile and ctfe run conveniently.

On Monday, 5 August 2013 at 17:15:34 UTC, Dicebot wrote:
> On Monday, 5 August 2013 at 16:50:12 UTC, monarch_dodra wrote:
>> This is currently "package", but it proves that what you asked for is not only possible, it is implemented *and* used in phobos.
>
> topic-starter has been asking about _language_ feature and my answer was related to this possible _language_ feature. Existence of some template in Phobos does not prove anything here.

Well, it's not about *proving* anything :/

Technically, the question asked was: "Are compile-time unittests possible in D?", so I'm not even sure the question *was* strictly about language.

But even if someone asks if a "language" can *do* something you *have* to take into account what the library can do. For example, D doesn't have "native" octals because they are library implemented. Does this mean that "D doesn't have octals" ?

So sure, I guess that strictly speaking, no, D language doesn't have static unittests. However, when someone asks the question, if you just answer "No" without pointing out that the language allows this semantic:

version(unittest) assertCTFEAble!({
    //YOUR CODE HERE
});

Then I believe you are giving an incomplete answer.

On Monday, 5 August 2013 at 17:30:38 UTC, monarch_dodra wrote:
> static assert({int i; assert(i == 0;});

enum i;
static assert(i == 0);

I am really struggling to understand the use case.
D has a tool to force CTFE execution - `enum`. It has a tool for compile-time checks - `static assert`. Any possible compile-time test can be expressed via those. All assertCTFEable or similar tool adds is ability to save on some `static` markers.

On Monday, 5 August 2013 at 17:38:22 UTC, monarch_dodra wrote:
> So sure, I guess that strictly speaking, no, D language doesn't have static unittests. However, when someone asks the question, if you just answer "No" without pointing out that the language allows this semantic:
>
> version(unittest) assertCTFEAble!({
>     //YOUR CODE HERE
> });
>
> Then I believe you are giving an incomplete answer.

Well, the problem is, D does have static unit-tests in a form of `static assert`. But topic starter has immediately provided an example that shows that his understanding of "static unit-tests" is different one, making it pretty hard to reason about proper alternative.

Even assertCTFEAble does not _exactly_ match what was asked here. Thus I feel the need to first ask about specific use case and only then propose any real solutions.

So, yes, of course, it is incomplete - because question is incomplete and requires further clarification. Which is the main point.