Why think unit tests should be in their own source code hierarchy instead of side-by-side

[Atila Neves]

On Thursday, 22 March 2018 at 17:09:55 UTC, Marco Leise wrote:
> I understand your opinion and I think it is all reasonable. You 
> talk about longer compile times since every D module is like a 
> C++ header. That touches one of my pet peeves with the language 
> or eco system as it stands and I wonder if you would agree with 
> me on the following:
>
> Libraries should be tied into applications using interface
> files (*.di) that are auto-generated by the compiler for the
> _library author_ with inferred function attributes. If after
> a code change, a declaration in the *.di file changes, the
> library's interface changed and a new minor version must be
> released. The language must allow to explicitly declare a
> function or method as @gc, impure, etc. so the auto-inferred
> attributes don't later become an issue when the implementation
> changes from e.g. a pure to an impure one.
> Opaque struct pointers as seen in most C APIs should also be
> considered for *.di files to reduce the number of imports for
> member fields.
>
> That means:
> * No more fuzzyness about whether a library function
>   will remain @nogc, @safe, etc. in the next update.
> * Explicit library boundaries that don't recursively import the
>   world.

I like it but I'd have to think about it a bit more.

My current idea to save me from staring at the screen for 2s at a 
time several times a day is to write a program using dmd as a 
library and integrate it into reggae that gets all of the 
dependencies from a given module. Then the build system reggae 
would generate would _not_ declare those dependencies, but 
actually .di files generated from them. That way a rebuild would 
only happen if the .di file changed, which the program would be 
smart enough to not overwrite if the hash/diff hasn't changed.

Atila