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.
