Program size, linking matter, and static this()

[Jonathan M Davis]

On Friday, December 16, 2011 14:44:48 Andrei Alexandrescu wrote:
> On 12/16/11 1:41 PM, Jonathan M Davis wrote:
> I understand and empathize with the sentiment, and I agree with most of
> the technical points at face value, save for a few details. But there
> are other things at stake.
> 
> Consider scope. Many arguments applicable to application code are not
> quite fit for the standard library. The stdlib is the connection between
> the compiler innards, the runtime innards, and the OS innards all meet,
> and the role of the stdlib is to provide nice abstractions to client
> code. Inside the stdlib it's entirely expected to find things like
> __traits most nobody heard of, casts, and other things that would be
> normally shunned in application code. I'd be more worried if there was
> no possibility to do what we need to do. The standard library is not a
> place to play it nice. We can't afford to say "well yeah everyone's
> binary is bloated and slower to start but we didn't like the cast that
> would have taken care of that".

I'm not completely against this precisely because of this, but at the same 
time, it strikes me as completely ridiculous to have to resort to some nasty 
casting simply to reduce the binary size of the base executable. I'd much 
rather see the compiler improved such that this isn't necessary.

> As another matter, there is value in minimizing compulsive work during
> library startup. Consider for example this code in std.datetime:
> 
> shared static this()
> {
> tzset();
> _localTime = new immutable(LocalTime)();
> }
> 
> This summons the garbage collector right off the bat, thus wiping off
> anyone's chance of compiling and linking without a GC - as many people
> seem to want to do. And that happens not to programs that import and use
> std.datetime, but to program using any part of the standard library that
> transitively imports std.datetime, even for the most innocuous uses, and
> even if they never, ever use _localtime! That one line essentially locks
> out 75% of the standard library to anyone wishing to ever avoid using
> the GC.

This, on the other hand, is of much greater concern, and is a much better 
argument for using the ugly casting necessary to get rid of the static 
constructors, even if the compiler did a fanastic job at cutting out the extra 
cruft in the binary - though as far as the GC goes, it might not be an issue 
once CTFE is good enough to create classes at compile time that still exist at 
runtime. Unfortunately, the necessity of tzset would remain however.

> > And honestly, I think that a far worse problem with static
> > constructors is circular dependencies. _That_ is something that
> > needs to be addressed with regards to static constructors. In general
> > at this point, it's looking like static constructors are turning out
> > to be a bit of a failure on some level, given the issues that we're
> > having because of them, and I think that we should fix the language
> > and/or compiler so that they _aren't_ a failure.
> 
> Here I totally disagree. The design is sound. The issues discussed here
> are entirely detail implementation artifacts.

As far as the binary size goes, I completely agree that it's an implementation 
issue, but I definitely think that the issues with circular dependencies is a 
design issue which needs to be addressed. The basics of static constructors 
wouldn't have to change drastically, but there should at least be a way to 
indicate to the compiler that there is not actually a circular dependency. I 
don't think that I have ever seen druntime blow up on a circular dependency 
where there was actually a circular dependency. It's just that the compiler 
(or druntime or both) isn't smart enough to determine whether the static 
constructors _actually_ create a circular dependency. It has no way of 
determining which module's static constructors should be called first and givse 
up. We need a way to give it that information so that it can order them when 
they aren't actually interdependent. _That_ is the design flaw that I see in 
static constructors, and it's one of the most annoying issues in the language 
IMHO (which arguably just goes to show how good D is in general, I suppose).

- Jonathan M Davis