D compiles fast, right? Right??

[Steven Schveighoffer]

On 4/2/18 4:05 PM, Jonathan M Davis wrote:

> One concern I have is version(unittest) blocks. In order to avoid code
> breakage, those would need to still be compiled in. I know that I've
> personally used version(unittest) blocks that had package access level and
> were then imported in the unit tests within that package in order to avoid
> declaring helper types or functions in each module. So, treating
> version(unittest) blocks like they're not there when importing a module
> would definitely break som existing code. It could be argued that such uses
> should be deprecated in some manner, but simply not compiling in anything
> related to -unittest in imported modules would be a problem. However, aside
> from maybe __traits(getUnitTests), I don't see why it would be a problem to
> ignore code inside a unittest block except for when that module is being
> compiled (or when that unittest block is inside a template that's being
> compiled).

version(unittest) blocks would have to be rethought in your code at some 
point. I think they have to go through the same rules -- only if 
__traits(getUnitTests) is used would it be included.

I have run into horrible problems with version(unittest), where I 
actually defined a virtual function (by accident, of course) for 
unittests only, and then when you compile/link with different modes of 
-unittest you have spectacular failure. There have been similar problems 
in phobos: https://github.com/dlang/phobos/pull/5932

There are other ways to achieve the same things, and while not as 
convenient, they would be safer and less troublesome for imports.

-Steve