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