On Thu, 02 Apr 2015 08:37:26 +0200, Jacob Carlborg wrote: > On 2015-04-01 21:25, Dicebot wrote: > >> I 100% disagree. Having built-in unittest blocks have been a huge win >> for the language and greatly improved quality of library ecosystem. >> Value of standardization and availability is tremendous here. >> >> Only problem is that development of the feature has stopped half way >> and there are still small bits missing here and there. All your >> requested features can be implemented within existing unittest feature >> via custom runner - while still running tests properly with default >> one! > > The the unittest block itself could have been easily implemented as a > library solution, if we had the following features: > > * Trailing delegate syntax * Executable code at module scope > > module bar; > > unittest("foo bar") > { > } > > Would be lowered to: > > unittest("foo bar", { > > }); > > These two features are useful for other things, like benchmarking: > > benchmark { > }
executable code at module scope isn't really necessary, i believe. it's just a little messier with mixin templates, but i believe that it's acceptable: mixin template foo(alias fn) { static this () { import iv.writer; writeln("hello! i'm a test!"); fn(); writeln("test passed"); } } // and do it mixin foo!({assert(42);}); // or with trailing delegate sugar: mixin foo!{ assert(42); }; sure, `static this` can do anything we want; registering unittest delegate in some framework, for example.
signature.asc
Description: PGP signature