On Wednesday, 7 October 2015 at 10:03:11 UTC, Johannes Pfau wrote:
Am Wed, 07 Oct 2015 08:41:30 +0000
schrieb Jonathan M Davis <jmdavisp...@gmx.com>:
On Wednesday, 7 October 2015 at 07:08:39 UTC, extrawurst wrote:
> Method 1: Adding a static c'tor to every module does not
> work very long in practice (as experienced first handed)
> cause you are in "cyclic c'tor hell" very quick...
The cyclic dependency checking in druntime makes static
constructors almost unusable. It's a case of being protected
so much while trying to do something that you can't do what
you're trying to do. There really should be some way IMHO to
have something similar to @trusted where you tell the
compiler/runtime that the order does not matter for a
particular static constructor and that it should just trust
the programmer on that, but Walter rejected the idea when it
was brought up.
- Jonathan M Davis
With LDC you can abuse the C constructor mechanism to do that.
GDC does not yet expose C constructors to D code but it's on my
list and it's easy to implement.
I'm not quite sure what you mean by C constructors, so I don't
know how that works, but unless it's in all of the compilers, I
don't think that it's really worth much ultimately. And we _do_
have workarounds already. std.stdio is an example of one such
module where what is essentially its static constructor is called
by another module in order to break the cycle. But then you lose
out on the special benefits of static constructors with regards
to initializing stuff like immutable objects, which can be a
problem - particularly when stuff like pure gets involved.
Honestly, I think that if we don't want it to be considered
borderline bad practice to use static constructors, I think that
we need a solution for this that allows them to function normally
without being concerned about circular dependencies (at least
when the programmer marks them as such). And if the C constructor
mechanism that you're talking about somehow does that, then
great, but it needs to be standard D, or it's a pretty limited
solution.
- Jonathan M Davis
