TickDuration deprecation

[Steven Schveighoffer]

On 11/18/17 9:03 AM, Timon Gehr wrote:

> (Jonathan M Davis from comment #4)
>  > TickDuration will soon be deprecated, and none of the other time stuff
>  > supports floating point. Anyone who wants that functionality can 
> calculate
>  > the floating point values from the integral values that the types do
>  > provide. It's not something that most code should be doing, but the API
>  > makes it possible for those who care.
> 
> 
> "Not something that most code should be doing"? I have never used 
> StopWatch and then /not/ wanted to do something like to!("seconds",double)!
> 
> There seems to be no good reason to break my code beyond requiring a 
> different import here. What are the perceived shortcomings of the 
> to!("seconds", double) interface?

My take on this, as someone who has argued extensively NOT to use double 
for timing calculations (I was responsible for adding the TimeSpan type 
in Tango (the equivalent of Duration) and marginalizing Interval (based 
on double) [1]):

1. All OS calls with timing requirements use non-floating point to 
represent how long to sleep. After all a CPU uses discrete math, and the 
timing implementation is no different.

2. Sometimes it is VERY important to use exact representation for 
everything.

   Example: I want to sleep for 1 microsecond, if you had a function 
that accepts a floating point value, and you pass in 0.000_001, you 
might actually sleep for 0 ticks, which is vastly different.

3. Sometimes it is not as important.

   Example: if you want to sleep for 1.75 seconds, having a function 
that converts the float representation of 1.75 into a Duration is 
useful, and reasonably accurate. It isn't going to ruin your application 
if the sleep passed to the OS is 1.749999999 seconds. Your sleep 
probably isn't going to be exactly accurate anyways, as most of use use 
non-real-time OSes.

4. There are many libraries, the most obvious one to me is Apple's core 
library, which use a double for representing time everywhere. So it's 
not without precedent.

5. Responding to Walter's one-liner resistance, if the one liner is 
trivial to get right, then sure, don't include it. It could even be 
written in-line. But if it's easy to get WRONG, or is annoying to have 
to write, then I think it's worth having, even if it's a one-liner.

    In my opinion, type conversion is one of those things that falls 
into that second category. How can I construct the most accurate 
Duration with a given double that is in the form of seconds? You'd have 
to know the representation of Duration as hectonanoseconds in order to 
get this right. While trivial to write once you *know* that, it's not 
trivial to write if you *don't*. Having a library function (even a 
one-liner) that says "I'll save you from the implementation details" is 
useful.

   related: https://github.com/dlang/druntime/pull/1927

   Bottom line: one-liner-ness shouldn't be an automatic disqualifier.

-----------

After having used Apple's SDK quite a bit, I've changed my opinion 
slightly since my Tango days. It is useful to have a floating point 
representation of time, and can be used to good effect. I would be fine 
with a mechanism to convert to/from double with a Duration in druntime 
(in fact, Tango kept this), but still want to have the representation be 
as accurate as possible when it comes to calling OS functions. All the 
public APIs of druntime/phobos should take/return only Durations, not 
doubles, and let the user convert if they want to use doubles elsewhere.

-Steve

[1] http://dsource.org/projects/tango/ticket/671