Static constructors in circularly imported modules - again

[Max Samukha]

On 27.05.2010 13:37, Max Samukha wrote:
> 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.

Feature-frozen. Sorry.

>
> 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.

I'd really appreciate a reply from the language designers. What are the 
plans?

1. Static constructor semantics won't change.
2. We've worked out a solution and it will be implemented in a future 
compiler release.

Please care to type 1 or 2. Thank you!