Program size, linking matter, and static this()

[Jonathan M Davis]

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