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.

On Wednesday, 22 November 2017 at 22:17:05 UTC, Walter Bright wrote:
> 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.

It's fixed point, not floating point, but this famous software disaster is a pretty dramatic example: http://www-users.math.umn.edu/~arnold/disasters/patriot.html

+1 to using integer arithmetic for the low-level time APIs.

On 2017-11-23 12:55, sarn wrote:
> +1 to using integer arithmetic for the low-level time APIs.

and nobody is advocating to change this.

it is about being able to use such result (duration) with non-time focused libraries/functions (eg. general maths/stats) expecting doubles.

if this is not possible in an obvious/standard way (being to!... in D) this is the very moment all potential python-to-D converts will run away screaming. putting the solution for this common problem only in the docs will not appease them either but rather make them mock D.

i still don't understand how problems could arise from a supported one-way conversion -> double. of course, double -> time or duration is something different and i tend to agree that this should be left for the user to implement.

i for my part could live with just one supported to!double conversion resulting in seconds. (i guess i am biased as i prefer to use SI units only for all my calculations.)

/det

On 2017-11-22 22:41, Walter Bright wrote:

> For another example, unreferenced virtual functions never get elided because a reference to them does exist - they're in the virtual function pointer table. And then, of course, everything that virtual function references is never elided.

Yeah, that's one of the reason why the original Objective-C/D bridge resulted in a 60 MB Hello World executable. At that point we realized we need to add direct support in the compiler for linking with Objective-C.

-- 
/Jacob Carlborg