Timer functions should maybe not take milliseconds as an argument

[alexcrichton]

System timers often expose a granularity much more fine than one millisecond. Right now this is an artifact of libuv's api, but in a 1:1 context you can get much finer-grained control over this.

Perhaps the arguments should be a (second/nsec) struct (like in C), with sugar to do the "easy thing"

[alexcrichton]

Ideally these would take a "Time" or "Duration" structure which has nanosecond precision (or something like that).

Nominating because this API will determine the backwards compatibility of timers.

[sfackler]

+1 for a Duration type or at the very least a unit and magnitude (e.g. 1, time::Seconds).

[alexcrichton]

One thought I had this morning is that if we don't have a solution for a "time type" by 1.0, we could rename all these functions to foo_ms and then deprecate them once we have the true function, but that also seems... bad.

[pnkfelix]

Accepted for 1.0 backcompat-libs.

[brson]

If we create a duration type here we should consider it's forward compatibility with #14657. We may end up in a situation where Duration ends up defined somewhere like core and reexported in a bunch of places.

[alexcrichton]

It may end up being the case that this is the correct API for the standard library, and the correponding time library will provide an extension trait to use an external Duration type (just one possibility)

[brson]

The rust-chrono Duration type supports ns: https://github.com/lifthrasiir/rust-chrono/blob/master/src/chrono/duration.rs

[brson]

cc @lifthrasiir discussing how timers want a duration type.

[brson]

I have a branch that does the following:

• Adds rust-chrono's Duration under std::duration
• Renames the sleep, periodic, and oneshot functions to sleep_ms, periodic_ms, oneshot_ms
• Adds back those functions, but taking Duration.

Looking for feedback.

[huonw]

The public API should probably use i32 etc. like the internals (rather than int and uint), and maybe it could be std::time rather than std::duration? (The latter is a complete bikeshed, I have no strong opinion at all.)

[lifthrasiir]

@huonw FYI, rust-chrono now uses i32 and u32 for public APIs. I've thought a bit hard about that, and reached the conclusion that keeping int and uint is not worth enough to take a risk.