static unittest

[H. S. Teoh via Digitalmars-d]

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