On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:

> On 12/16/11 12:40 PM, Jonathan M Davis wrote:
>> On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
>>> 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.
> 
> This goes back to the issue of lazy initialization. Today you need a cast to do that. Here's my code:
> 
>    static @trusted @property long ticksPerSec() pure nothrow
>    {
>        return (cast(immutable(long) function() pure nothrow) &ticksPerSecImpl)();
>    }

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.

On Friday, December 16, 2011 11:07:14 Sean Kelly wrote:
> On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:
> > On 12/16/11 12:40 PM, Jonathan M Davis wrote:
> >> On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
> >>> 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.>
> > This goes back to the issue of lazy initialization. Today you need a cast
to do that. Here's my code:
> > static @trusted @property long ticksPerSec() pure nothrow
> > {
> > 
> > return (cast(immutable(long) function() pure nothrow)
> > &ticksPerSecImpl)();>
> > }
> 
> 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.

Agreed.

- Jonathan M Davis

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.

Andrei

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."  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.  I do agree that the design is already there, but perhaps the implementation needs refinement?

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

On Dec 16, 2011, at 2:54 PM, Andrei Alexandrescu wrote:

> 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!")

Perhaps it's just that I come from a systems programming background and have books like "Large Scale C++ Software Design" sitting on the shelf next to me.  I think the important distinction to be made is between sample code and real world code.  Or perhaps between code where performance is and is not an issue.  You've historically derided the quicksort example for functional programs as useless because, while it's a very clean example of the algorithm, it's ridiculously inefficient.  So anyone who really cares about the efficiency of their code is going to end up writing stuff that looks nothing like what you'd find in a textbook.  In short, they're going to write code that looks like standard library code to whatever extent the skill of their programmers can achieve.  I really don't want the line between whether or not to use really useful language features like static ctors to be whether I'm writing sample code or professional code.

That said, I will grant that library code in general can't make any assumptions about how the code will be used, so this is the one case where premature optimization really is prudent.  Even performance-minded application code typically can't make the same claim because there is generally some idea of how that code will be run, and thus tuning can be done based on profiler data.  So I suppose I'll somewhat concede your point.