Tracking Issue for constify-ing non-trait `Duration` methods

[marmeladema]

This is a tracking issue for constify-ing non-trait Duration methods

The feature gates for the issueis #![feature(duration_consts_float)]. The methods covered by that are:

• Duration::as_secs_f64
• Duration::as_secs_f32
• Duration::as_millis_f64
• Duration::as_millis_f32
• Duration::div_duration_f64
• Duration::div_duration_f32

Steps

• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

XXX --- list all the "unresolved questions" found in the RFC to ensure they are
not forgotten

Implementation history

• Constify most non-trait Duration methods as described: Constify most non-trait Duration methods as described in #72440 #72481
• Make all methods of Duration unstably const: Make all methods of Duration unstably const #76335
• Partially stabilize duration_consts_2: Partially stabilize duration_consts_2 #89542

[marmeladema]

I also would like to add a Duration::MAX associated const. Should it be part of the same tracking issue?

[Mark-Simulacrum]

I don't think so -- adding a new constant seems pretty orthogonal to me.

[marmeladema]

I don't think so -- adding a new constant seems pretty orthogonal to me.

It's orthogonal but depends on Duration::new being const so I thought having a tracking issue just for one associated const might be overkill.

[RalfJung]

Because they end up calling f32|64::is_finite which ultimately call mem::transmute which is not const.

FWIW, #72449 makes the other safe transmute wrappers const. Once that lands, abs_private and is_finite could also be made const.

[RalfJung]

All right, #72449 will make is_finite const as well, so you should be able to use that.

[marmeladema]

Great! I'll wait for #72449 to land and update my PR accordingly.

[RalfJung]

The tracking issue should also notice that stabilizing any of the f32/f64 methods is blocked on stabilizing floating point in const at all (#57241).