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].
>
> [...]

How would this work with separate compilation?

On Tuesday, 21 May 2019 at 09:43:32 UTC, Atila Neves 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].
>>
>> [...]
>
> How would this work with separate compilation?

I assume with the proposal of Andrei, even the separate compilation can be solved.
Of course the points of Jacob (https://forum.dlang.org/post/qbtrre$ilr$1@digitalmars.com) have to be investigated and addressed in detail.

Kind regards
André

Am Sun, 19 May 2019 19:13:31 +0000 schrieb Andre Pany:

> 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.
> 
> Kind regards Andre

Do you happen to have a link for that original post?

@Andrei how exactly should something like this be implemented, do you agree that mixin templates are the right tool for this (e.g. as described here: https://forum.dlang.org/post/qbr7dd$16fd$1@digitalmars.com)? If so, I could write a DIP and the compiler implementation for that. Of course the DIP would have to adress the details (selective imports, public imports, ...), but I'd like to have some feedback on the general idea* first.

* annotate template mixin with import, then automatically add mixin(template(thisModule))) in every importing module

-- 
Johannes

On Tuesday, 21 May 2019 at 17:54:36 UTC, Johannes Pfau wrote:
> Am Sun, 19 May 2019 19:13:31 +0000 schrieb Andre Pany:
>
>> [...]
>
> Do you happen to have a link for that original post?
>
> @Andrei how exactly should something like this be implemented, do you agree that mixin templates are the right tool for this (e.g. as described here: https://forum.dlang.org/post/qbr7dd$16fd$1@digitalmars.com)? If so, I could write a DIP and the compiler implementation for that. Of course the DIP would have to adress the details (selective imports, public imports, ...), but I'd like to have some feedback on the general idea* first.
>
> * annotate template mixin with import, then automatically add mixin(template(thisModule))) in every importing module

Here the link
https://forum.dlang.org/post/q7l56r$bo6$1@digitalmars.com

Kind regards
Andre

On 2019-05-21 11:43, Atila Neves wrote:

> How would this work with separate compilation?

Hmm, I'm not sure. That would be tested when it's implemented :)

-- 
/Jacob Carlborg

On Tuesday, 21 May 2019 at 20:04:38 UTC, Jacob Carlborg wrote:
> On 2019-05-21 11:43, Atila Neves wrote:
>
>> How would this work with separate compilation?
>
> Hmm, I'm not sure. That would be tested when it's implemented :)

Testing in production is the best way to test things. It is known. :P

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.

On 2019-05-21 11:43, Atila Neves wrote:

> How would this work with separate compilation?

I have given this some more thought. For my idea to work, regardless of separate compilation, I think the compiler needs to invoke a template that uses `__traits(getRootModules)` which collects all tests. If it's not a template I'm guessing this would contain the files passed to the compiler when druntime was built and not when the user application is built.

Then it would collect the unit tests to a global variable, that should work with separate compilation as well, I think.

-- 
/Jacob Carlborg

On Thursday, 23 May 2019 at 18:01:32 UTC, Jacob Carlborg wrote:
> On 2019-05-21 11:43, Atila Neves wrote:
>
>> How would this work with separate compilation?
>
> I have given this some more thought. For my idea to work, regardless of separate compilation, I think the compiler needs to invoke a template that uses `__traits(getRootModules)` which collects all tests. If it's not a template I'm guessing this would contain the files passed to the compiler when druntime was built and not when the user application is built.
>
> Then it would collect the unit tests to a global variable, that should work with separate compilation as well, I think.

One thing I do not understand. Once module A, which contains the new traits, is compiled using separate compilation, the list of found modules is fixed. If now new module B is added, nothing will cause a rebuild of A and therefore the list of found modules is incomplete.

This can of course be solved by telling the user to not use separate compilation, which might be a fair tradeoff, I am not sure.

Kind regards
Andre

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.