Fixing cyclic import static construction problems
Artur Skawina
art.08.09 at gmail.com
Wed Nov 28 22:36:41 PST 2012
On 11/29/12 03:34, Walter Bright wrote:
> Proposed Solution:
>
> Add a pragma,
>
> pragma(cyclic_imports);
>
> This can appear anywhere in a module, and applies globally to that module.
> It means that static constructors from imports that are not part of the cycle
> are run first, and that the static constructor for this module may be run before
> the static constructors of other modules that are part of the cycle.
Bad name. Something like "module_ctors_unordered" would be better (I don't
like that one either, but this way it's at least clear what it does).
The equivalent attribute version could be
module mymodule @unordered_ctors;
which is better, but still has the problem that adding another module ctor
can result is silent breakage. These things can be mixed in, so something
as innocent looking as
import some_lib;
[...]
mixin blah;
can already be a bug. Hence:
static this() @unordered { /*whatever*/ }
and then either enforce that all mod-ctors have this attribute (otherwise
every ctor in that moduile gets treated as ordered), or split them into
two sets (better, but larger change; backward compatible, just requires
a new enough runtime to be used).
Of course it could be also done as
static this() pragma(unordered) { /*whatever*/ }
but this wouldn't really be better, and would require language change (the
fact that you cannot attach a pragma to /anything/ is already a problem,
eg for gcc-specific attributes).
"@unordered" could even be inferred, but I'm not sure how often that would
help in practice. At least w/o making module-level imports invisible inside
module ctors (which would make the deps explicit).
artur
More information about the Digitalmars-d
mailing list