TickDuration deprecation

[Walter Bright]

On 11/21/2017 11:48 PM, Jon Degenhardt wrote:
> 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.

My perspective is that the time package should not deal with floating point at 
all. I understand that it is useful in some circumstances to treat them as 
floating point values, but this should be a layer added on by the user, not by 
the time package.


> In the older version of StopWatch, this last step conversion could be done with 
> a call like:
> 
>      double ms = sw.peek.to!("msecs", double));

That puts the logic of the double conversion into the time package.


> 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.

I agree. It is a prime candidate for further encapsulating in a function, such as:

     /* Returns: duration in milliseconds to 4 digits past the decimal point */
     double swAsDouble(StopWatch sw) { return sw.peek.total!("hnsecs").to!double 
/ 1e+04); }

     double ms = swAsDouble(sw);

This function, being a trivial one liner, doesn't really need to be in Phobos. 
It could be suitable for inclusion in the time package documentation as an 
example on how to get results in a floating point manner.

[As a general philosophy, I oppose Phobos being filled with one liners, a mile 
wide and an inch deep. Phobos should be a small number of non-obvious, 
orthogonal, deep functions. As an extreme example,
    int add2(int i){return i+2;}
should not be in Phobos.]


> 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.

It is not the rationale I would use for this case.

It's also true that floating point operations are a minefield with respect to 
precision and roundoff decisions. These sorts of decisions should not even be 
made by the time package, because they will always be wrong for some users, so 
they should rightfully be pushed to the user.