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
