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
parent 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
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 "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
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 "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
prev sibling next sibling 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 next sibling parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
--f46d0442807650199c04f845d902
Content-Type: text/plain; charset=UTF-8

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

--f46d0442807650199c04f845d902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">std.exception.assertCTFEable ?</p> <p dir=3D"ltr">Kenji Hara</p> <div class=3D"gmail_quote">2014/05/01 1:56 &quot;Andrei Alexandrescu via Di= gitalmars-d&quot; &lt;<a href=3D"mailto:digitalmars-d puremagic.com">digita= lmars-d puremagic.com</a>&gt;:<br type=3D"attribution"><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> Walter and I also discussed &quot;static unittest&quot; a while ago - yes, = another use of static :o).<br> <br> A static unittest would be evaluated only during compilation, and would pro= ve things that fall in the realm of static checking but are not verifiable = with traditional typesystem approach.<br> <br> That won&#39;t enable things we can&#39;t do today (there&#39;s always asse= rt(__traits(compiles, ...)) but it&#39;s instantly recognizable, very easy = to use, and pushes semantic checking to a whole new level.<br> <br> Thoughts?<br> <br> <br> Andrei<br> </blockquote></div> --f46d0442807650199c04f845d902--
Apr 30 2014
prev sibling next sibling 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 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 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
prev sibling next sibling parent "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
prev sibling next 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
prev sibling 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