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
