static unittest

[Meta via Digitalmars-d]

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.