www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static unittest

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 30 2014
next sibling parent reply "Meta" <jared771 gmail.com> writes:
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


There's also

unittest
{
     static assert(...);
}
Apr 30 2014
next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 30 April 2014 at 16:57:13 UTC, Meta wrote:

 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


 There's also

 unittest
 {
     static assert(...);
 }


I've been doing this a lot lately. Since I wrote a unit test 
library I use that for all my unit tests, but the compilation 
ones are usually implementation details that don't need external 
tests. I started adding static asserts to the file that needed 
them but got lost in what was implementation and what was a test 
so I started wrapping all the static asserts in unittest blocks. 
Works for me.



Atila
Apr 30 2014
parent "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 30 April 2014 at 17:03:58 UTC, Atila Neves wrote:

 On Wednesday, 30 April 2014 at 16:57:13 UTC, Meta wrote:

 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


 There's also

 unittest
 {
    static assert(...);
 }


 I've been doing this a lot lately. Since I wrote a unit test 
 library I use that for all my unit tests, but the compilation 
 ones are usually implementation details that don't need 
 external tests. I started adding static asserts to the file 
 that needed them but got lost in what was implementation and 
 what was a test so I started wrapping all the static asserts in 
 unittest blocks. Works for me.



 Atila


Having said that, I did think (and probably will) of writing a 
staticEquals for unit-threaded so at least I don't have to keep 
building up the string to print out for myself every time.

Atila
Apr 30 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 30, 2014 at 04:57:12PM +0000, Meta via Digitalmars-d wrote:

 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).




Yeah I think 'static' is getting a little too overloaded in D. But in
this case, I think it's excusable. :-P



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.




[...]

 There's also
 
 unittest
 {
     static assert(...);
 }


Yeah, what does static unittest give us beyond static assert? (Other
than nice syntax, that is.)

Or are you suggesting that code inside a static unittest will be CTFE'd
and elided from the emitted object code?  That could be nice.

Speaking of which, it would be nice if there was a way to elide
CTFE-only functions from the object code, e.g.:

	real complicatedComputation(real arg) {
		...
		return result;
	}
	enum x = complicatedComputation(5.0);

Supposing that complicatedComputation() is never used except to assign a
value to x, it would be nice to be able to omit it from the executable.
Especially if it's a template function -- it will cut down on template
bloat.

Currently one way to hack this is:

	real complicatedComputation(real arg) {
		if (__ctfe)
		{
			...
			return result;
		}
		else
			return real.nan; // UGLY
	}
	enum x = complicatedComputation(5.0);

This minimizes the executable bloat (ld --gc-sections could help, but
that is known to break in some circumstances), but it's ugly since the
function still has to return *something*.


T

-- 
Many open minds should be closed for repairs. -- K5 user
Apr 30 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 30 2014
parent "Dicebot" <public dicebot.lv> writes:
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
Apr 30 2014
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.


Isn't (__traits(compiles, ...) in a static assert redundant? All 
it does is replace one compilation error for another, 
additionally hiding its details.
Apr 30 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 10:00 AM, Vladimir Panteleev wrote:

 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.


 Isn't (__traits(compiles, ...) in a static assert redundant? All it does
 is replace one compilation error for another, additionally hiding its
 details.


Not if you want to compile statements. -- Andrei
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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


http://forum.dlang.org/post/enlgrnfrfsfldaxiaoug forum.dlang.org
Apr 30 2014
prev sibling next sibling parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
std.exception.assertCTFEable ?

Kenji Hara
2014/05/01 1:56 "Andrei Alexandrescu via Digitalmars-d" <
digitalmars-d puremagic.com>:


 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
Apr 30 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 30 2014
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
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.
Apr 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 30 2014
parent reply "Meta" <jared771 gmail.com> writes:
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.
Apr 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 30 2014
parent "Meta" <jared771 gmail.com> writes:
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.
May 01 2014
prev sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
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.
Apr 30 2014