On Wednesday, 30 April 2014 at 17:24:32 UTC, Andrei Alexandrescu wrote:
> On 4/30/14, 10:11 AM, H. S. Teoh via Digitalmars-d wrote:
>> Yeah, what does static unittest give us beyond static assert? (Other
>> than nice syntax, that is.)
>
> static assert is for expressions, static unittest is for statements.
>
> Andrie

See linked thread, it was extensively discussed there. TL; DR: delegates + https://github.com/D-Programming-Language/phobos/blob/master/std/exception.d#L1401

On 2014-04-30 18:55, Andrei Alexandrescu wrote:
> Walter and I also discussed "static unittest" a while ago - yes, another
> use of static :o).
>
> A static unittest would be evaluated only during compilation, and would
> prove things that fall in the realm of static checking but are not
> verifiable with traditional typesystem approach.
>
> That won't enable things we can't do today (there's always
> assert(__traits(compiles, ...)) but it's instantly recognizable, very
> easy to use, and pushes semantic checking to a whole new level.
>
> Thoughts?

It's already possible to do CTFE unit testing [1], if that was what you're thinking about.

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

-- 
/Jacob Carlborg

On Wednesday, 30 April 2014 at 16:55:06 UTC, Andrei Alexandrescu wrote:
> Walter and I also discussed "static unittest" a while ago - yes, another use of static :o).
>
> A static unittest would be evaluated only during compilation, and would prove things that fall in the realm of static checking but are not verifiable with traditional typesystem approach.
>
> That won't enable things we can't do today (there's always assert(__traits(compiles, ...)) but it's instantly recognizable, very easy to use, and pushes semantic checking to a whole new level.
>
> Thoughts?
>
>
> Andrei

Also, while we're thinking about static unittest, what about contracts? I've seen Bearophile suggest it quite a few times, and I agree that it'd be very useful to have contracts that are able to check a subset of function contracts/object invariants at compile time.

On 4/30/2014 1:38 PM, Meta wrote:
> Also, while we're thinking about static unittest, what about contracts? I've
> seen Bearophile suggest it quite a few times, and I agree that it'd be very
> useful to have contracts that are able to check a subset of function
> contracts/object invariants at compile time.

Already have them - template constraints.

On Wednesday, 30 April 2014 at 21:04:19 UTC, Walter Bright wrote:
> On 4/30/2014 1:38 PM, Meta wrote:
>> Also, while we're thinking about static unittest, what about contracts? I've
>> seen Bearophile suggest it quite a few times, and I agree that it'd be very
>> useful to have contracts that are able to check a subset of function
>> contracts/object invariants at compile time.
>
> Already have them - template constraints.

Your function needs to be a template for that. Also, object invariants.

On 4/30/2014 2:34 PM, Meta wrote:
> On Wednesday, 30 April 2014 at 21:04:19 UTC, Walter Bright wrote:
>> On 4/30/2014 1:38 PM, Meta wrote:
>>> Also, while we're thinking about static unittest, what about contracts? I've
>>> seen Bearophile suggest it quite a few times, and I agree that it'd be very
>>> useful to have contracts that are able to check a subset of function
>>> contracts/object invariants at compile time.
>>
>> Already have them - template constraints.
>
> Your function needs to be a template for that.

Adding () turns a function into a function template. Also, static asserts.

> Also, object invariants.

Easily handled with static asserts.

Le 30/04/2014 18:55, Andrei Alexandrescu a écrit :
> Walter and I also discussed "static unittest" a while ago - yes, another
> use of static :o).
>
> A static unittest would be evaluated only during compilation, and would
> prove things that fall in the realm of static checking but are not
> verifiable with traditional typesystem approach.
>
> That won't enable things we can't do today (there's always
> assert(__traits(compiles, ...)) but it's instantly recognizable, very
> easy to use, and pushes semantic checking to a whole new level.
>
> Thoughts?
>
>
> Andrei

Can be usefull on our project DQuick. Maybe my friend will be able to speek more on how much it's interesting.

On Wednesday, 30 April 2014 at 22:14:44 UTC, Walter Bright wrote:
> On 4/30/2014 2:34 PM, Meta wrote:
>> On Wednesday, 30 April 2014 at 21:04:19 UTC, Walter Bright wrote:
>>> On 4/30/2014 1:38 PM, Meta wrote:
>>>> Also, while we're thinking about static unittest, what about contracts? I've
>>>> seen Bearophile suggest it quite a few times, and I agree that it'd be very
>>>> useful to have contracts that are able to check a subset of function
>>>> contracts/object invariants at compile time.
>>>
>>> Already have them - template constraints.
>>
>> Your function needs to be a template for that.
>
> Adding () turns a function into a function template. Also, static asserts.
>
>> Also, object invariants.
>
> Easily handled with static asserts.

Just a thought, this might be a good idea for the problem of not knowing which condition fails when a template instantiation fails, i.e.:

auto reduce(alias fun, Args...)(Args args)
//We don't know which condition fails when this template fails to instantiate
if (Args.length > 0 && Args.length <= 2 && isIterable!(Args[$ - 1]))
{
    //...
}

Instead we could do:


auto reduce(alias fun, Args...)(Args args)
static in
{
    assert(Args.length > 0);
    assert(Args.length <= 2);
    assert(isIterable!(Args[$ - 1]));
}
body
{
    //...
}

And the error message which show you exactly which condition failed. You could also just use static asserts in the contract, but the topic of this thread is about `static unittest`, which is more or less redundant as well.