2015-09-27 14:01 GMT+09:00 Jonathan M Davis via Digitalmars-d < [email protected]>:
> This DIP provides a way to handle unittest blocks inside of templates > which works with ddoc without compiling the unittest blocks into each > instantiation. > > http://wiki.dlang.org/DIP82 > > > At present, we really can't put unittest blocks - including ddoc-ed > unittest blocks - inside of templated types, which has been a problem for > Phobos and came up again just the other day when someone was helpful and > went and tried to turn the examples in std.datetime's *Interval types in > ddoc-ed unit tests, but we had to reject the changes, because it would have > resulted in those tests being compiled into every instantiation of those > templated types, polluting the code of anyone who uses them as well as > making the Phobos unit tests take longer to run for no extra benefit > whatsoever. > > So, I wrote up this DIP in the hopes of solving the problem in a clean and > simple manner which fits in well with the existing language features. Interesting proposal. Quick questions: 1. I think the token `static` should be placed at the immediate front of `unittest` static unittest { ... } static nothrow unittest { ... } // NG It's consistent with the behavior of `static this()` family. 2. Currently the members of template won't be semantically analyzed until it's instantiated. So, when the `static unittest` is enclosed in other blocks, how it works? template Foo(T) { // inside conditional compilation blocks: static if (is(T == int)) { static unittest { ... } } version (UserDefinedVersion) { static unittest { ... } } debug (UserDefinedDebugId) { static unittest { ... } } // inside block/labeled attributes nothrow { static unittest { ... } } @safe: static unittest { ... } mixin("static unittest { ... }"); mixin(makeStaticUnittest()); } string makeStaticUnittest() { return "static unittest { ... }"; } Kenji Hara
