D compiles fast, right? Right??

[Jonathan M Davis]

On Monday, April 02, 2018 17:15:40 Steven Schveighoffer via Digitalmars-d 
wrote:
> 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.

I do think that there's some value in being able to do version(unittest) to
code and import it, but I can certainly live with losing that ability if
it's really needed to fix the situation with unit tests being compiled in
when they shouldn't. Regardless, my main point was that there is existing
code which relies on the current behavior. So, if we want to change that
behavior without just pulling the rug out from under existing code, we're
going to need some sort of deprecation process for it, whereas I would think
that it would be possible to stop compiling unittest blocks when importing
modules without breaking any code.

- Jonathan M Davis