TickDuration deprecation

[Timon Gehr]

On 22.11.2017 03:22, Walter Bright wrote:
> On 11/21/2017 1:40 PM, Timon Gehr wrote:
>>> Computer clocks have discrete ticks, they are not continuous.
>> That may be true, but the plotting library may still just expect a 
>> list of doubles. What's the point of removing the simple conversion 
>> function that was already available for such use cases? This is a 
>> breaking change with zero benefits.
> 
> I'm in general opposed to "kitchen sink" abstractions, preferring 
> pluggable component abstractions.

But this is orthogonal to my complaint. I don't care which Phobos module 
contains the conversion functionality. It can be part of std.conv.to, 
for example.

> Floating point has no business being 
> in a type that is represented as an integral type.

Why would it need to be part of the type? I just want the obvious 
conversion functionality, to enable further processing where this is 
appropriate.

> There are no 0.3 clock ticks, the notion does not exist.
> ...

(Great then. There also is no 0.3 float value. :P)

> 
>>> The behavior maps cleanly onto integral math,
>> I'm not doing computations on times. I could just use Duration for that.
> 
> Time durations are always discrete quanta by the nature of the clock used.
> ...

The plotter or whatever other component consumes the timing data might 
not care about this.

> 
>>> not fuzzy fp math.
>> There is nothing fuzzy about floating point operations,
> 
> Fuzzy as in inexact.

The result is well-defined, it's just rounded. Whether that is exact or 
not depends on what you expected the result to be, it's not properly 
part of the floating point abstraction.

> Integral time computations are always an exact 
> multiple of clock ticks.
> ...

The reason why floating point values are popular is that it is often 
enough infeasible or unnecessary to do the computation without rounding. 
The output of a computation might be inexact even if the inputs are not. 
There needs to be some way to move from one regime to the other.

> 
>> but still, yes, for some use cases, the tiny rounding error will just 
>> not matter.
> 
> Whether the rounding error matters or not should not be decided by the 
> time package, it should be decided by what the user decides to do with 
> the time values.
> 
> I.e. it is not properly part of the time abstraction.
> 

My claim is not that conversion from time to floating point values 
associated with a few natural units is "properly part of the time 
abstraction", just that it should exist. Do you agree with that?