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

[via Digitalmars-d-bugs]

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

--- Comment #16 from Jonathan M Davis <jmdavisProg at gmx.com> ---
(In reply to Steven Schveighoffer from comment #15)
> (In reply to Jonathan M Davis from comment #11)
> > 
> > I'm not opposed to something like durLit!("1.2552", "seconds") which is then
> > essentially a Duration literal which can be a floating point value. However,
> > using floating point values for time at runtime is just begging for bugs,
> > and such code should be avoided with extreme prejudice.
> 
> I don't agree with that. It depends on the purpose of the duration value.
> Note that Objective-C uses Interval to represent all durations, and it is a
> typedef of double. I have not had any adverse experience with it.

Every application that I've seen use doubles for time has had bugs because of
it. It works in a lot of cases, but you end up with subtle problems as a
result. Durations aren't as bad as timestamps, but it's still asking for
trouble. It's just far better IMHO to avoid the floating point values entirely
and not have to deal with those bugs, especially because using floating point
values generally doesn't buy you much.

(In reply to Vladimir Panteleev from comment #14)
> > while being a royal pain for anyone who wanted to use floating point values
> > for time directly
> 
> I think that's objectively false: just add `.text`

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.

With something like dur!"seconds"("1.5") or seconds("1.5"), the folks who want
literals are fine, as is anyone getting user input, but we avoid directly
supporting folks using floating point values for durations, and we avoid
floating point errors with regards to literals or user input, whereas using
actual floating point values risks floating point errors.

--