TickDuration deprecation

[Jonathan M Davis]

On Saturday, November 18, 2017 15:03:05 Timon Gehr via Digitalmars-d wrote:
> This is quite annoying:
>
> void main(){
>      import std.datetime;
>      StopWatch sw;
>      import std.stdio;
>      writeln(sw.peek().to!("seconds",double));
> }
>
> This gives the deprecation warning:
> Deprecation: struct std.datetime.StopWatch is deprecated - Use
> std.datetime.stopwatch.StopWatch.
>
> Then, if I do that:
>
> void main(){
>      import std.datetime.stopwatch: StopWatch;
>      StopWatch sw;
>      import std.stdio;
>      writeln(sw.peek().to!("seconds",double));
> }
>
> Error: no property 'to' for type 'Duration'
>
> This is among the most basic use cases for StopWatch. For example, if I
> want to quickly plot some timing data, I'll invariably want to convert
> times to floating point values of the correct units.
>
> The reason given for this situation is:
> https://issues.dlang.org/show_bug.cgi?id=11353
>
> (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?

core.time and std.datetime avoid floating point math, because using it
introduces errors into the calculations. It does make some sense to generate
a floating point value if all you're looking to do is print it out at the
end, but using floating point values in the calculations is a source of bugs
- e.g. converting between clock frequencies using floating point values
would be particularly bad, much as it's the obvious first implementation;
core.time.convClockFreq does it all with integral math and avoids the
problem and even manages to support a higher range of values in the process
than it would if it were implemented with double or real.

As such, I've avoided floating point values like the plague in the time
stuff. The only reason that TickDuration does it at all is because it was
written by someone else, and it has various design flaws that mean that it
really should never have been in core.time in the first place (most notably
that it conflates a point in time of the monotonic clock a a duration of the
monotonic clock, making it really easy to screw up when using it). So, we've
slowly been moving towards getting rid of it in favor of using MonoTime and
Duration.

Printing out a floating point value for something like the number of seconds
can make sense, but using floating point to do math with time really
doesn't. And it's trivial enough to do the math yourself to get the number
of seconds (or milliseconds or minutes or whatever) as a floating point
value if you really want that that I'd much rather not add it to core.time,
because that would just be encouraging folks to start using floating point
values for something other than simply printing out the value, which will
lead to buggy code which could have easily been avoided just by sticking to
integral math.

Folks have asked for the ability to create Durations from floating point
values too, and I rejected that for the same reason - using floating point
values with time is just begging for bugs, and Walter backed me up on that
one.

- Jonathan M Davis