Bug 6113 – singletons in std.datetime are not created early enough

When accessing the singletons from a shared static this module ctr, the singleton have not been instantiated. The following code succeeds when it shouldn't: import std.datetime; shared static this() { assert(UTC() is null); assert(LocalTime() is null); } A possible solution is: class Test { shared static this() { _obj = new immutable(shared(Object)); } shared static immutable Object _ojb; } shared static this() { assert(Test._ojb !is null); }

There's now a pull request with the fixes: https://github.com/D-Programming-Language/phobos/pull/81 Given the simplicity of the change, I expect that it'll be merged in fairly quickly.

While changing them to shared static ctors is a good change, I there might well be a real bug here anyway. For the main thread's initialization, should it run through all shared static ctors then all non-shared static ctors as two passes? Or, should it run through all shared static and non-shared statics together in one pass?

That's why I opened bug# 6114. I'm going to close this one once my fix has been merged in, since that fixes the problem with std.datetime. But there _is_ a compiler bug here. Bug# 6114 covers that. Everything that I've read says that the static constructors are supposed supposed to be run in lexical order within a module, and the the compiler will order the initialization of the modules such that they're run in the order necessary to initialize everything before it's used. I haven't seen anything that would indicate that hared static constructors should be treated any differently from other static constructors as far as initialization order goes.

Fixed as far as std.datetime goes: https://github.com/D-Programming-Language/phobos/commit/ba7d70b85802e5626708545c96e38f91fcf5c341 The underlying problem ( bug# 6114 ) still exists though.

Why was this closed? The following code still failed: import std.datetime; shared static this() { assert(UTC() !is null); assert(LocalTime() !is null); } void main() {}

While we are on the subject, does anyone have a suggestion on how to write unit test that test this? Or do we need to extend the unittest capability?

This _was_ fixed. If it's broken again, it's likely a bug in dmd or druntime related to the order of static constructors. It's probably releated to bug# 6631.

Well, like I said, this was fixed previously and is only a problem in the current release due to bug# 6331. However, in git, UTC and LocalTime have been changed to be lazily loaded thanks to some casting hackery, so this is no longer an issue regardless of the state of bug# 6331.