On Friday, December 16, 2011 22:41:14 Timon Gehr wrote: > On 12/16/2011 09:31 PM, Jonathan M Davis wrote: > You don't need a C function if you just factor out every variable it > initializes to the separate D module. __fileinit.d works that way. I > don't see why stdiobase.d could not do the same.
That only works if the variable being initialized is in the new module instead of the original module, which you can't always do. > > It works, but it's not pretty (and it doesn't always work > > - e.g. std.datetime), and it would be _far_ better if you could just > > mark a static constructor as not depending on anything or mark it as > > not depending on a specific module or something similar. > > How would that be checked? It wouldn't be. It wouldn't need to be. The programmer is telling the compiler that there isn't a dependency. It's up to the programmer to make sure that it's right, and it's wrong, it's their fault. There are plenty of other features like that in D - just not SafeD. > > annoying issues in D IMHO. > Adding a language construct that turns off the checking entirely (as you > seem to suggest) is not at all better than having to create a few > additional source files. I completely disagree. For instance, it's impossible to move the singleton instances of UTC and LocalTime from std.datetime into another module without breaking encapsulation, and it's definitely impossible to do it and leave them as members of their respective classes. Those static constructors clearly don't rely on any other modules except for the one which gives the declaration for tzset (and has no static constructors). But if std.file needed a module constructor, we'd end up with a circular dependency between std.datetime and std.file when clearly nothing in std.datetime's static constructor relies on std.file in any way shape or form. It would be a huge improvement to be able to just mark those static constructors as not relying on any other modules having their static constructors run first. As it stands, it's a royal pain to deal with any circular dependencies which pop up and because of that, it quickly becomes best practice to avoid static constructors as much as possible, which is a big problem IMHO. Factoring out the static constructor's contents into a separate module is not always possible, and it's an ugly solution IMHO. I'd _much_ rather have a feature where I can tell the compiler that there is no circular dependency so that it can appropriately order the loading of the modules. - Jonathan M Davis