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
