Change:
/// # Examples /// /// ``` <del> /// #![feature(duration_saturating_ops)] </del> /// #![feature(duration_constants)] /// use std::time::Duration; /// /// assert_eq!(Duration::new(0, 0).saturating_add(Duration::new(0, 1)), Duration::new(0, 1)); /// assert_eq!(Duration::new(1, 0).saturating_add(Duration::new(u64::MAX, 0)), Duration::MAX); /// ``` <del> #[unstable(feature = "duration_saturating_ops", issue = "76416")] </del> <ins> #[stable(feature = "duration_saturating_ops", since = "1.53.0")] </ins> #[inline] #[rustc_const_unstable(feature = "duration_consts_2", issue = "72440")] pub const fn saturating_add(self, rhs: Duration) -> Duration {

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for saturating operations. The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the proposal: [x] FCP [x] Stabilization PR: <!-- Include any open questions that need to be answered before the feature can be stabilised. --
Just needed when dealing with time intervals. Also, unresloved questions seem to be from another tracking issue?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I am very happy to see this stabilized. One thing I wanted to discuss is the documentation: it currently mentions two associated constants: But both are currently unstable. Should they be stabilized at the same time? Or should the documentation updated?

It seems a bit weird that the documentation for stable methods is mentioning unstable features and therefore the code examples cannot be executed and verified on stable. This is really a newbie question, I don't know what is the correct approach here. I am pretty sure such circumstances have happened before? Also, once that question is resolved, I would be very glad to do the stabilization PR. It's my first tracking issue and it would kind of be a personal accomplishment :+1:
is being stabilized at the same time: still needs to be stabilized. it's suggested that that constant should probably not be part of the same tracking issue as the other constants there (, etc.). Feel free to send a PR that stabilizes just , then we can do an FCP on that PR and we'll remove it from that tracking issue. Feel free to make that PR without waiting for . In this specific case I don't think it's a problem if this gets stabilized while the docs still refer to something unstable. is pretty clear and uncontroversial. Even if it's unstable, it's still the best way we have to refer to the maximum value of a . (And it'll probably be stable anyway in ~two weeks.)