Program size, linking matter, and static this()

[Martin Nowak]

> Yes they are. static constructors completely chicken out on them. Not  
> only is
> there no real attempt to determine whether the static constructors are
> actually dependent (which granted, isn't an easy problem), but there is  
> _zero_
> support in the language for resolving such circular dependencies.  
> There's no
> way to say that they _aren't_ dependent even if you can clearly see that  
> they
> aren't. The solution used in Phobos (which won't work in std.datetime  
> due to
> the use of immutable and pure) is to create a C module which has the  
> code from
> the static constructor and then have a separate module which calls it in  
> its
> static constructor.
Which is a hack because that C function is a compiler wall while the  
dependency
persists. Btw. that stdiobase and datebase are obsolete the cycles have  
vanished.

You will get this only if std.dateparse had a shared static ctor too.
   Cycle detected between modules with ctors/dtors:
   std.date -> std.dateparse -> std.date
   object.Exception at src/rt/minfo.d(309): Aborting!

There is a cleaner hack to solve the issue but I really don't like it.
It's two DAGs that are iterated one for "shared static this" and
one for "static this".

----
module a;
import b;

shared static this()
{
}
----
module b;
import a, core.atomic : cas;

shared bool initialized;
static this()
{
     if (!cas(&initialized, false, true)) return;
     ...
}
----