Named unittests and __traits(getModules)

[Paul Backus]

On Sunday, 19 May 2019 at 22:41:52 UTC, Andrei Alexandrescu wrote:
> On 5/19/19 8:13 PM, Andre Pany wrote:
>> On Sunday, 19 May 2019 at 18:56:33 UTC, Jacob Carlborg wrote:
>>> I'm staring a new thread here on the topic of Name unittests 
>>> because the existing one is getting too long [1].
>>>
>>> [...]
>> 
>> As far as i remember there was another suggestion of Andrei 
>> (in another context). By importing a module B in module A, the 
>> module B can specify coding which is executed and gets the 
>> module A as info.
>> 
>> This might could also solve this issue.
>
> Yah, it's quite a universal pattern. It can be used as "import 
> core.rtti; to add RTTI support for this module" etc.

Allowing import statements to have side effects seems like a 
pretty big can of worms to open just so that we can avoid typing 
"mixin RTTISupport!()". One of the great things about D's module 
system is that a D module can't meddle around in another module's 
global scope the way a header file can in C or C++. I hope that 
guarantee won't be broken simply for the sake of syntactic 
convenience.