Named unittests and __traits(getModules)

[Andrei Alexandrescu]

On 5/22/19 5:08 PM, Paul Backus wrote:
> 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.

Good point, thanks.