Add saturating methods for Duration
#76114
Merged
Conversation
This file contains 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
|
r? @shepmaster (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
jyn514
added
the
T-libs-api
marmeladema
force-pushed
the
duration-saturating-ops
branch
from
044ca51 to
904ec9f
Compare
pickfire
reviewed
Aug 31, 2020
|
Why the PR close? |
|
@shepmaster I really don't know what happened. I never meant to close this! |
3 tasks
marmeladema
force-pushed
the
duration-saturating-ops
branch
from
904ec9f to
30aa7dd
Compare
|
@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
marmeladema
force-pushed
the
duration-saturating-ops
branch
from
30aa7dd to
b869aa5
Compare
|
@pickfire I've fixed the docs according to your comments 👍 |
|
@bors r+ rollup |
|
📌 Commit b869aa5 has been approved by |
bors
added
S-waiting-on-bors
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`
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?