[Issue 6725] core.time.dur should accept floating point

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6725

Vladimir Panteleev <thecybershadow at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow at gmail.com
         Resolution|WONTFIX                     |DUPLICATE

--- Comment #7 from Vladimir Panteleev <thecybershadow at gmail.com> ---
Considering how difficult it is to convert an FP value to a Duration, I
definitely think that this behavior belongs in the standard library.

https://github.com/D-Programming-Language/druntime/pull/905

(In reply to Walter Bright from comment #6)
> 1. Using floating point for time is like using floating point for accounting
> software ($57.23). It doesn't work for things that come in discrete quanta
> (pennies, clock ticks). You will spend FAR more time chasing weird problems
> than you will save in "convenience". Yes, I have experience with this, and I
> understand floating point (having build FP emulators).

This argument is exaggerated. Not all measurements of time need to be precise.
For example, if an utility program could accept a timeout value from the user,
it's more useful to allow them to specify a fractional value.

> 2. Many machines have very poor FP performance compared with integer
> performance. Implementing basic operations using unnecessary FP results in
> slow, bloated code.

FP code will only work when the user passes FP values to Druntime functions. It
does not affect existing code. I don't see how this argument applies.

> 3. Phobos' time functions are already massively complex. I still can't even
> compile the datetime unittests on a 512Mb machine. Please, no more.

"dur" is in Druntime (core.time), not Phobos. I have created a patch already,
and it is rather simple.

> 4. It's trivial for a user to write their own FP wrapper around dur.

I disagree, it is not trivial.

> There is no reason to integrate this into dur itself.

I disagree, it is a useful addition that I wished a few times would be there.

> Software should be pieced together using layers of abstraction,
> not kitchen sink base types.

I don't see how this applies here. Making the functions generic does add more
abstraction.

> 5. It would take longer to read the documentation for this enhancement than
> to just convert your floating point value to an int.

I believe that's objectively wrong.

> 6. You're not forced to write long complicated expressions to convert fp to
> integers. It's just a scale and a cast:
> 
>     dur!("secs")(1.5001) => dur!("nsecs")(cast(long)(1.5001 * 1000000));

I think this is a bad solution because:

1. It does not operate on the actual resolution of Duration, which is hnsecs.
Forcing the user to move that up to their user code would imply a leaky
abstraction.

2. Did he type 6 zeroes, or only 5? It's forcing the use of magic numbers. The
non-magic-number expression has already been posted here (`convert!("seconds",
"hnsecs")(1)`), but it makes the expression even bulkier.

3. It's duplicating logic which already exists in core.time. Opening up the
existing conversion code to accept FP values was trivial - the existing
algorithms takes care of FP values just fine.

*** This issue has been marked as a duplicate of issue 13176 ***

--