Resolution of core.time.Duration...

[Jonathan M Davis]

> On Tue, 17 May 2011 09:42:27 -0400, Daniel Gibson <metalcaedes at gmail.com>
> 
> wrote:
> > Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
> >> I agree that accepting a long as an alternative to Duration, it makes
> >> sense to use a more normal tick resolution. The chances of someone
> >> wanting to have their process sleep for more than 300 years (e.g. for
> >> nanosecond resolution) is pretty small. This might be a worthwhile
> >> change.
> >> 
> >> I'm not sure how much code this might affect, though. It would be
> >> plenty disturbing if your code started sleeping for 100ms instead of the
> >> 10s you thought you requested. What might be a good path is to disable
> >> those functions that accept a long for a few releases, then re-instate
> >> them with a new meaning.
> > 
> > Or just add nanoSleep() or something like that.
> 
> Probably a good idea, and deprecate Thread.sleep(long). It's more
> self-documenting.

I very much support the idea of deprecating all of the functions in druntime 
and phobos which take naked time values. And then if a function that sleeps at 
nanosecond resolution is considered to be of real value (which I question), 
then we can add that as something like nanoSleep.

I believe that at present, most - if not all - of the function in druntime in 
Phobos which take a naked time value (aside from std.date) also take a 
Duration now, but I don't think that any of the old versions which take naked 
values are scheduled for deprecation. If there is a valid reason for wanting 
to keep any of them around, then we should consider it, but I'm definitely 
inclined to get rid of them in favor of the greater safety and maintainability 
of functions which take a Duration.

- Jonathan M Davis