Static constructors in circularly imported modules - again

Max Samukha spambox at d-coding.com
Thu May 27 03:37:50 PDT 2010


There was a discussion about those a while ago that terminated with 
Andrei's authoritative "it would be a step backward".

I am not entirely convinced that there had been a step forward in the 
first place. Defining static construction order to be determined by the 
module import graph had been a half step forward. Completely disallowing 
static construction of circularly imported modules - a half step 
backward. The result is std.stdiobase and impossibility to initialize 
static data in mixins without resorting to lazy initialization.

I can live with hacks like std.stdiobase when such are possible. What is 
more critical is initialization of mixins. Restating the problem:

module a;
mixin template Foo()
{
    static immutable Object foo;
    shared static this()
    {
        foo = cast(immutable)new Object;
    }
}

----
module b;
import a;
import c;

mixin Foo;

----
module c;
import a;
import b;

mixin Foo;

In this scenario one is forced to avoid static constructors by lazily 
initializing foo and using some kind of synchronization, which should be 
absolutely unnecessary and sometimes is not tolerable.

So which of the following is going to happen?

1. The current blinkered design will stay.
2. A solution will be provided before D2 is feature-freezed.

Note that I am well aware of 
http://yosefk.com/c++fqa/ctors.html#fqa-10.12 etc, but simply 
disallowing static construction is not a good solution for static 
construction problems.


More information about the Digitalmars-d mailing list