Tracking issue for duration_constants

[frewsxcv]

Implemented in #57375

This will make working with durations more ergonomic. Compare:

// Convenient, but deprecated function.
thread::sleep_ms(2000);

// The current canonical way to sleep for two seconds.
thread::sleep(Duration::from_secs(2));

// Sleeping using one of the new constants.
thread::sleep(2 * SECOND);

impl Duration {
    pub const SECOND: Duration = Duration::from_secs(1);
    pub const MILLISECOND: Duration = Duration::from_millis(1);
    pub const MICROSECOND: Duration = Duration::from_micros(1);
    pub const NANOSECOND: Duration = Duration::from_nanos(1);
    pub const MAX: Duration = ...;
}

[oli-obk]

Currently these constants are free constants in the std::time module. I think we should consider moving them onto the Duration type as associated constants.

[SimonSapin]

Associated constants would reduce the (typical) number of imports in code using this. @stjepang @frewsxcv what do you think?

I’ll FCP to merge once this is resolved one way or another.

@SimonSapin We should definitely do that!

Another related constant is UNIX_EPOCH, which was introduced as std::time::UNIX_EPOCH in 1.8.0:
https://doc.rust-lang.org/nightly/std/time/constant.UNIX_EPOCH.html

Then, in 1.28.0, it was added again as associated constant SystemTime::UNIX_EPOCH:
https://doc.rust-lang.org/nightly/std/time/struct.SystemTime.html#associatedconstant.UNIX_EPOCH

Following that precedent, I'd infer associated constants would probably be more idiomatic here.

@SimonSapin I think we're ready for FCP to merge now.

[SimonSapin]

Updated the issue description.

@rfcbot fcp merge