On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: > On 12/16/11 3:49 AM, Jonathan M Davis wrote: > > On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: > >> On 12/16/11 1:12 AM, Jonathan M Davis wrote: > >>> Simply making it so that std.file is only imported in std.stdio with > >>> version(unittest) cut off _that_ much? > >> > >> Yah, but the matter is more complex. The issue is that std.file pulls > >> std.datetime, which (a) has static this() code, and (b) pulls > >> core.time, > >> which in turn has static this() code. > >> > >> The issue with that is as follows. Any file that transitively imports > >> a > >> module with constructors will have its own module info generated. When > >> that happens, all vtables in that module will be instantiated, so all > >> methods will be linked in. That in turn causes all functions they call > >> to also be linked in. > >> > >> That's why many programs using std are large. > >> > >> We can attack this in two ways: > >> > >> 1. Revise and reduce all static this() uses in phobos and druntime; > >> > >> 2. Improve the compiler to do minimal linking when static this() does > >> come about. > > > > Well, both std.datetime and core.time need static this() and can't not > > have it. > > I am pretty sure they don't need static this(). Only last night I > removed static this() from core.time.
I don't know how you could do that in core.time, since ticksPerSec and appOrigin are immutable and have to be set at runtime. How on earth can you do that without a static constructor? std.datetime has the same problem with the added fun of having to avoid breaking purity, because the functions for getting the singletons are pure. - Jonathan M Davis