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
