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
