On Sunday, April 08, 2012 06:45:20 Kapps wrote: > On Sunday, 8 April 2012 at 04:09:45 UTC, Jonathan M Davis wrote: > > As for double, it should work. SHOO had had functions similar > > to seconds, > > msecs, usecs, and nsecs which defaulted to real, but I removed > > them a while > > back, because it made it too confusing to keep them all > > straight. But to > > should work with integral values with a size of at least 4 > > bytes as well as > > all floating point types. The unit tests do test real, but they > > don't test > > double at all. So, it's possible that there's a bug which > > prevents it from > > working, but both float and double should work. If they don't, > > it's a bug which > > needs to be reported and fixed. > > > > - Jonathan M Davis > > That's actually something I've been wondering about for a while. > I have never once (once I knew that they returned fixed point > numbers and fixed the bugs that caused) used the > msecs/seconds/etc properties, because you almost never want such > low precision. It would be much nicer to be able to just write > .seconds instead of .to!("float", seconds), but returning a ulong > prevents me being able to do that. Is there any reason those > properties don't return float or double? It's probably too late > to do anything about that at this point though even if it was > desired.
There were properties which did both, but they were confusing, because it wasn't obvious which used long and which used real. Using long matched everything else in core.time and std.datetime, and none of the rest used floating point values for anything, so that's what was kept. But you should be able to use to!("float", seconds). If that doesn't work, it's a bug. float, double, and real should all work with TickDuration's to. - Jonathan M Davis