DIP82: static unittest blocks

[Jonathan M Davis via Digitalmars-d]

On Sunday, 27 September 2015 at 15:06:28 UTC, Jonathan M Davis 
wrote:
> On Sunday, 27 September 2015 at 10:32:00 UTC, Kenji Hara wrote:

>> 2. Currently the members of template won't be semantically 
>> analyzed until it's instantiated. So, when the `static 
>> unittest` is enclosed in other blocks, how it works?
[snip]

Another possibility is that because a static unittest block only 
matters when the module that it's in is compiled - and only when 
compiled with -unittest - we could make it so that a template has 
full semantic analysis done on it (or at least whatever is 
necessary to compile static unittest blocks) when it's the module 
that it's in which is being compiled (and -unittest is used), 
whereas when the module is merely imported, or -unittest is not 
used, only what's done currently gets done, and static unittest 
blocks can be ignored when the template is instantiated or 
-unittest is not used. And doing that would even work with mixins.

It still wouldn't work to have static unittest blocks inside of 
static if blocks or mixins that required any template arguments, 
but the rest should work as long as the semantic analysis is done 
when the module that the template is in is being compiled with 
-unittest, and the static unittest blocks inside of code that 
can't be semantically analyzed without instantiating the template 
can be errors when the template gets instantiated (since that 
would be better than having them silently do nothing).

That would increase compilation times for templates when 
compiling the module that they're in with -unittest, but it would 
only be when compiling that module with -untitest and not for 
anyone importing the module, so I think that the additional cost 
would be worth it - particularly in light of how it harms 
maintenance to have to put all of the unittest blocks outside of 
the template like we do now.

- Jonathan M Davis