Cyclic dependencies vs static constructors

[Steven Schveighoffer]

On 12/19/17 2:04 PM, Jonathan M Davis wrote:
> 
> The fact that static constructors can't properly handle circular
> dependencies does mean that there's a tendancy to throw them under the bus
> at some point, which can be a serious problem. Andrei has been jumping
> through all kinds of insane hoops recently in an attempt to remove all
> static constructors from Phobos, which is going a bit far IMHO, but that's
> open for debate, and if the result works properly, I don't know how much I
> care, though I'm disinclined to jump through those sort of hoops in my own
> code.

But that's not because of circular dependencies, that's to allow those 
pieces of phobos to be independent of druntime.

However, it does (as a side effect) eliminate the need for proper 
construction order, at the cost of more expensive access to the global data.

> In the past, I suggested that we have some sort of attribute for a static
> constructor that tells the compiler and runtime that there isn't really a
> circular dependency - either by indicating that it isn't circularly
> dependent on anything or by telling it what the dependency order is so that
> the load order for the modules can be dealt with correctly - but Walter
> rejected the idea on the grounds that it was too risky. Not only would it be
> easy to get wrong to begin with, but if the code changed later, actual,
> circular dependencies could go unnoticed and result in some pretty nasty
> bugs.

But this doesn't even solve the problem of decoupling the grouping of 
types/data into a related module from the problem of static 
construction. That is, you may import other modules for reasons totally 
separate from static construction.

The only idea I had that makes things a bit better is to ignore imports 
inside unit tests (since those are only ever run after static 
construction anyway).

Maybe there are some other ways to do it. But none of them are going to 
be painless.

-Steve