TickDuration deprecation

[Walter Bright]

On 11/22/2017 5:45 AM, Steven Schveighoffer wrote:
> 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.

Microsoft has numerous COM APIs for time functions. One of them I had to deal 
with used doubles to represent seconds. This had to be interfaced with other 
time functions that used integers. The trouble came from round trips - there 
were cases where double=>integer=>double did not produce the same result. Even 
worse,

     double=>integer=>double=>integer=>double ...

produced a creeping shift in the value! It took much time to come up with a 
method of preventing such drift, and even that was unreliable.


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

Another solution is to put the one-liner not in Phobos, but in the documentation 
as an example of how to use it. The user will have to look up the function in 
the documentation anyway.


>    Bottom line: one-liner-ness shouldn't be an automatic disqualifier.

As always, use good judgement. You and I differ on where that line is, however. 
I prefer a small interface with a minimal number of orthogonal functions, from 
which I can assemble what I need. An interface with a blizzard of functions all 
doing overlapping things with unknown tradeoffs is cognitive overload.

The documentation of such an interface should, of course, provide examples of 
how to assemble those minimal functions into commonly needed solutions.

---

As an aside, Andrei has worked very hard trying to figure out how to break down 
the memory allocator into the smallest collection of orthogonal parts that can 
then be assembled *by the user* into whatever he needs. It is not obvious, and 
amazingly nobody has done it before.

https://dlang.org/phobos/std_experimental_allocator.html

He did the same thing with the checked int package, which blows away every other 
checked integer solution I've seen. I believe it's the future of How To Do 
Interfaces Right :-)

https://dlang.org/phobos/std_experimental_checkedint.html

The documentation for both is a bit intimidating, though. There should be a more 
tutorial oriented overview.