[D-runtime] druntime commit, revision 410

[Sean Kelly]

On Nov 5, 2010, at 11:43 AM, Fawzi Mohamed wrote:

> 
> On 5-nov-10, at 18:59, Sean Kelly wrote:
> 
>> On Nov 5, 2010, at 9:12 AM, Fawzi Mohamed wrote:
>>> 
>>> Using integers one has to somehow give access to the time unit in some way, and so make the interface more complex.
>>> If different timers have different resolution different structures have to be used.
>>> Thus they lead to a more complex interface.
>> 
>> I disagree.  With the Duration code, the call looks like this:
>> 
>>   Thread.sleep(seconds(5) + milliseconds(10))
>> 
>> How is that complex?  Though I'll admit that the double version is pretty straightforward too:
> 
> You are right, It is not complex if you use it only for that.
> But if later you want to use the same/similar structure for different clocks (probably outside the core), then you have problems if the other clock has a different resolution.

Resolution is only relevant insofar as the maximum and minimum duration that can be represented.  Using a signed 64-bit value at a nanosecond resolution, the maximum duration that can be represented is roughly 300 years, and bumping the resolution to 100ns increments (as in C#) would make this 30,000 years.  Is there really a need for multiple-resolution durations?  Perhaps duration should use a double internally as well?  One of my concerns of using std.datetime as-is is that I'd need 4 overloads of Thread.sleep(), one for each duration type.  This suggests to me that durations in std.datetime really weren't intended for independent use.

> I thought that having a uniform type outside the druntime was part of the reason for choosing Duration.
> In that case I find using a floating point number (normally a double) as duration is a good choice.
> 
>>   Thread.sleep(5.01)
>> 
>> Or the conversion routines could be changed to return a double instead of a Duration:
>> 
>>   double seconds(T)(T val) {
>>       return cast(double) val;
>>   }
>> 
>> etc.  I'll admit that I'm not absolutely crazy about dealing with doubles inside the wait routines themselves, but this could be solved by the addition of some library functions.  I'd probably basically just rip out Duration and replace it with a bunch of free functions that did essentially the same thing: long hours(double), long nanoseconds(double), long totalNanoseconds(double), etc.
> 
> I remember a discussion were also Walter didn't like floating points, but to say the truth, I think that sunning them is a thing of the past.
> (this has nothing to do with the fact that the clock itself should better use integers).

I wouldn't fight the use of double if it came to that.  More important to me is that durations be communicated clearly and that slicing them up is easy and error-free.  This could easily be solved by a set of functions similar to how Duration is used now without stepping on any toes by defining an actual Duration type.