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!
