TickDuration deprecation

[Jon Degenhardt]

On Wednesday, 22 November 2017 at 05:50:53 UTC, Walter Bright 
wrote:
> There is another, perhaps obsolete, consideration.
>
> Some CPUs do not have floating point units. C, for example, is 
> carefully set up so that when you don't need floating point, it 
> isn't required to have an FPU. This made C usable on cheap 
> processors.
>
> It's sorta like "why is the GC linked in even though I never 
> used it?"

Hi Walter - I wonder if there is a miscommunication. My 
understanding is that the question is whether there should be a 
built-in conversion from Duration to float/double in a specific 
unit of measure, like milliseconds. It sounds as if your concern 
is more to ensure that the time package not be required to 
support something other than integral values in its internal 
operations.

Perhaps there is an alternative perspective, but being able to 
convert a Duration to a double in a specific unit of measure 
would not seem to place any burden on the time package to support 
the result of conversion as a first class time object. In this 
view, what happens with the converted value is entirely in the 
hands of the end user, not the time package. If the user decides 
to use the double in a mathematical operation, floating point 
round off error is the responsibility of the user, not the time 
package.

To give a concrete example of why this is conversion is useful - 
I often do performance analysis involving service calls that take 
from single digit milliseconds to hundreds of milliseconds, with 
standard deviations in that ballpark. I might use tens of 
thousands of timing samples and analyze those samples using stats 
and graphing packages. Those packages all use doubles, and it is 
generally convenient to work in units appropriate for the 
measurements being done, milliseconds in the case I described. In 
this case, the last step in generating a timing value is to 
convert to milliseconds as a double and store it somewhere, often 
a log file. These will be read back in by the stats/graphing 
package, where follow-up processing will be done.

In the older version of StopWatch, this last step conversion 
could be done with a call like:

     double ms = sw.peek.to!("msecs", double));

In the new version, a call needs to be something like:

     double ms = sw.peek.total!("hnsecs").to!double / 1e+04);

The latter form is more error prone and less clear about intent, 
etc. It sounds as the rationale for depreciating the previous 
form of conversion is because the end user may incur floating 
point round-off error by performing mathematical operations on 
the double value. The user can still perform the conversion, but 
must go to greater effort. It sounds as if the other part of the 
rationale is that conversion is likely to be rare. In my 
experience, this is not the case.