static init cycle detection problem

[Brad Roberts]

On Thu, 20 Sep 2012, Jonathan M Davis wrote:

> On Thursday, September 20, 2012 20:49:32 ?ivind wrote:
> > Thanks for the explination. The trick you talk about has worked
> > for me before, but now I really need static init of modules that
> > depend on eachother. Only solution I can think of is to list all
> > modules in a script and generate d code from this to call init
> > functions.. Then pass it to dmd along with the other code.
> > 
> > Sad that we can't get this to work like it really should. D is a
> > very flexible language in many ways, and it seems strange that it
> > should not allow the stuff I want to do here..
> 
> If you have a true circular dependency, then you're just plain screwed and 
> need to redesign your code. That's fundamental and _can't_ be fixed.
> 
> Off the top of my head, the only reason that you wouldn't be able to use the 
> trick that std.stdio uses but not have a true circular dependency is if your 
> initializing const or immutable variables in a static constructor. But then 
> the solution is to refactor your code so that you don't have the circular 
> dependency, even if it's just moving those variables into a separate module, 
> which is generally quite feasible, even if it's not necessarily quite what you 
> wanted.
> 
> - Jonathan M Davis
> 

I'm not picking on Jonathan's response, just needed an entry point to the 
thread...

Static initializers are overused in D, particularly phobos and druntime, 
imho.  They're a particular problem when it comes to use in library code.  
Mixing static and dynamic linkage along with initialization == things 
break in wierd ways.  I'd _much_ rather see them moved into explicit api 
calls or removed entirely where possible.

Every static initializtion is unavoidable (by users of the 
library) overhead.

My 2 cents,
Brad