Add saturating methods for Duration#76114
Merged
bors merged 1 commit intorust-lang:masterfrom Sep 12, 2020
Merged
Conversation
Contributor
|
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
044ca51 to
904ec9f
Compare
pickfire
reviewed
Aug 31, 2020
Member
|
Why the PR close? |
Contributor
Author
|
@shepmaster I really don't know what happened. I never meant to close this! |
3 tasks
904ec9f to
30aa7dd
Compare
Contributor
Author
|
@shepmaster @pickfire I think i've addressed all the comments 👍 |
pickfire
reviewed
Sep 7, 2020
pickfire
reviewed
Sep 7, 2020
pickfire
reviewed
Sep 7, 2020
pickfire
reviewed
Sep 7, 2020
pickfire
approved these changes
Sep 7, 2020
Contributor
pickfire
left a comment
There was a problem hiding this comment.
Looks good to me except the mentioned doc changes.
30aa7dd to
b869aa5
Compare
Contributor
Author
|
@pickfire I've fixed the docs according to your comments 👍 |
Member
|
@bors r+ rollup |
Collaborator
|
📌 Commit b869aa5 has been approved by |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Sep 12, 2020
…, r=shepmaster Add saturating methods for `Duration` In some project, I needed a `saturating_add` method for `Duration`. I implemented it myself but i thought it would be a nice addition to the standard library as it matches closely with the integers types. 3 new methods have been introduced and are gated by the new `duration_saturating_ops` unstable feature: * `Duration::saturating_add` * `Duration::saturating_sub` * `Duration::saturating_mul` If have left the tracking issue to `none` for now as I want first to understand if those methods would be acceptable at all. If agreed, I'll update the PR with the tracking issue. Further more, to match the behavior of integers types, I introduced 2 associated constants: * `Duration::MIN`: this one is somehow a duplicate from `Duration::zero()` method, but at the time this method was added, `MIN` was rejected as it was considered a different semantic (see rust-lang#72790 (comment)). * `Duration::MAX` Both have been gated by the already existing unstable feature `duration_constants`, I can introduce a new unstable feature if needed or just re-use the `duration_saturating_ops`. We might have to decide whether: * `MIN` should be replaced by `ZERO`? * associated constants over methods?
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 12, 2020
Rollup of 7 pull requests Successful merges: - rust-lang#76114 (Add saturating methods for `Duration`) - rust-lang#76297 (rustdoc: fix min_const_generics with ty::Param) - rust-lang#76484 (Add MaybeUninit::assume_init_drop.) - rust-lang#76530 (Eliminate mut reference UB in Drop impl for Rc<T>) - rust-lang#76583 (Update `std::os` module documentation.) - rust-lang#76599 (Finish off revisions for const generics UI tests.) - rust-lang#76615 (Add missing examples on binary core traits) Failed merges: r? `@ghost`
m-ou-se
added a commit
to m-ou-se/rust
that referenced
this pull request
Apr 26, 2021
…ax, r=m-ou-se Stabilize Duration::MAX Following the suggested direction from rust-lang#76416 (comment), this PR proposes that `Duration::MAX` should have been part of the `duration_saturating_ops` feature flag all along, having been 0. heavily referenced by that feature flag 1. an odd duck next to most of `duration_constants`, as I expressed in rust-lang#57391 (comment) 2. introduced in rust-lang#76114 which added `duration_saturating_ops` and accordingly should be folded into `duration_saturating_ops` and therefore stabilized. r? `@m-ou-se`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In some project, I needed a
saturating_addmethod forDuration. I implemented it myself but i thought it would be a nice addition to the standard library as it matches closely with the integers types.3 new methods have been introduced and are gated by the new
duration_saturating_opsunstable feature:Duration::saturating_addDuration::saturating_subDuration::saturating_mulIf have left the tracking issue to
nonefor now as I want first to understand if those methods would be acceptable at all. If agreed, I'll update the PR with the tracking issue.Further more, to match the behavior of integers types, I introduced 2 associated constants:
Duration::MIN: this one is somehow a duplicate fromDuration::zero()method, but at the time this method was added,MINwas rejected as it was considered a different semantic (see core/time: Add Duration methods for zero #72790 (comment)).Duration::MAXBoth have been gated by the already existing unstable feature
duration_constants, I can introduce a new unstable feature if needed or just re-use theduration_saturating_ops.We might have to decide whether:
MINshould be replaced byZERO?