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

[via Digitalmars-d-bugs]

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

--- Comment #18 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Vladimir Panteleev from comment #17)
> (In reply to Jonathan M Davis from comment #16)
> > Would you honestly expect folks to be using to!string or text to convert
> > floating point values to Durations in their code on a regular basis? Sure,
> > someone might do it, but it's an extra layer of ugly and a performance hit
> > to do so. It doesn't _stop_ anyone from doing it, but it makes it hard
> > enough and ugly enough that I'd expect most people not to do it.
> 
> Erm, yes, it is much less hard or ugly than your solution in comment #5.

True,

auto d = dur!"seconds"(to!string(1.5001));

is not as ugly as

auto d = dur!"hnsecs"(cast(long)(convert!("seconds", "hnsecs")(1) * 1.5001)));

but it's definitely uglier than

auto d = dur!"seconds(1.5001);

and it incurs a performance hit when used in the cases when it shouldn't be
used, so it makes it less desirable.

I feel very strongly (as does Walter apparently) that using floating point
values for time calculations is very wrong and that we should not support it.
If it's enough of a usability boost to support floating point values as strings
in order to better deal with user input or duration literals for things like
calls to sleep, then I'm willing to consider it, but even then, I'm not a huge
fan of the idea. However, it's definitely more palatable than supporting
floating point values directly, because that would just encourage bad
practices. At least with strings, programmers would have to work at it a little
bit and incur a performance hit when they used floating point values that
weren't literals and weren't from user input. It's still not great, but
allowing strings is a compromise, and from the sounds of it, it covers your use
case.

--