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

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(...);
}

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.

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

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

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

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

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

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

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
>