https://issues.dlang.org/show_bug.cgi?id=14517
--- Comment #4 from Steven Schveighoffer <[email protected]> --- If you look at PR 990 that Jonathan linked, you will see that it's not so cut and dry. Essentially ANY separate compiled module that imports another module that has some template constructors, even if they aren't used in that module, but used somewhere else, will flag that module as having ctors. The test I ran showed modules like std.traits having module bits flipped on because of core.time having static ctors in an instantiated template. That makes no sense whatsoever -- there's not even an instantiation of MonoTimeImpl in std.traits. Let me first say that we need to fix this regardless of how it's done or how complete the fix is. We absolutely cannot mark some module as having static ctors because of modules somewhere else in the import chain that have nothing to do with the given module. If this means banning static ctor/dtor in templates, so be it (though I think that's a bit difficult to swallow). And thinking some more about my idea, I don't think it will work. What we likely need is a way to say that mod2 or mod3 can "upgrade" mod1's bit (at runtime). Perhaps we can discuss at dconf '15. --
