On 12/16/11 4:21 PM, Sean Kelly wrote:
On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:
On 12/16/11 1:07 PM, Sean Kelly wrote:
This is fine, but the whole point of static ctors in D is to
eliminate all the stupid workarounds required to use statics in
C++. I'd much rather we find a way to make the use of static
ctors more efficient than give up on the feature.
I agree, but then I think we have a design that's already there.
This discusses working some kinks out of the implementation. Also,
the context of the runtime/standard library is an appropriate place
to take less usual measures for the benefit of many.
But at the same time, the standard library should be an example of
how to do things "the right way."
More often, APIs and examples given in the docs are examples of how to
do things the right way; the standard library's implementation has a bit
of a different charter than most application code, and this is triply
true for systems languages. This is emphatically true for e.g. C, C++,
and Perl. I also remember I was surprised when I peeked inside a
functional language's library implementation. ("That's not how they
teach them to write sort!")
By preferring the C++ approach
over static ctors in the standard library, we're suggesting that
static ctors are not the right approach for the discriminating
programmer.
And they may as well not be, subject to whatever unique constraints to
overcome.
I do agree that the design is already there, but perhaps
the implementation needs refinement?
That's a given!
Andrei
