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