Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for 'checked_duration_since' feature #58402

Closed
vi opened this issue Feb 12, 2019 · 5 comments · Fixed by #62860
Closed

Tracking issue for 'checked_duration_since' feature #58402

vi opened this issue Feb 12, 2019 · 5 comments · Fixed by #62860
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@vi
Copy link
Contributor

vi commented Feb 12, 2019

There going to be checked analogues of offseting Instants by Durations, but I see no analogue of non-panicking calculation of Duration from a pair of Instants.

Note: this issue is referred by #[unstable] in the pull request.

@jonas-schievink jonas-schievink added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Feb 12, 2019
vi added a commit to vi/rust that referenced this issue Feb 12, 2019
@dtolnay
Copy link
Member

dtolnay commented Feb 15, 2019

Some use cases from @vi:

Most recent example from my code:

let rtt4 = if now >= send_time { now - send_time } else { Duration::from_secs(999)};

now.saturating_duration_since(send_time) would probably be OK for this, or a checked_duration_since with more explicit fallback.

The comparison was added when I suddenly encountered a panic.

A close call nearby:

if now < deadline {
    sleeper.sleep(deadline - now);
}

Although readable as is, using saturating_duration_since would be almost equally good.

That comparison is easy to miss, leading to panic when under load. Seeing checked/saturating analogues nearby in documentation puts one in "here be dragonsoverflows" mode and suggests care.

@vi vi changed the title No non-panicking analogue for Instant::duration_since Tracking issue for 'checked_duration_since' feature Feb 17, 2019
@vi

This comment has been minimized.

@dtolnay dtolnay added B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Feb 20, 2019
@faern
Copy link
Contributor

faern commented Mar 22, 2019

I just had good use for Instant::checked_duration_since. It's a good method to have when working with deadlines, as compared to timeouts. I get a deadline: Instant handed to me, and I need to figure out how far into the future it is without risking a panic:

deadline.checked_duration_since(Instant::now())

@faern
Copy link
Contributor

faern commented Apr 3, 2019

I do like checked_duration_since, and I would like that function stabilized. It both lowers the amount of code needed and lowers the risk of screwing up some check and ending up with a panic. It's already used by parking_lot here and here. And it can use it in even more places when it's stable.

However, I personally don't see the benefit of saturating_duration_since. It's a small convenience, but it does not help the user avoid panics like checked_duration_since does.

In the example posted above, regarding saturating_duration_since:

if now < deadline {
    sleeper.sleep(deadline - now);
}

The author hint that they would like to shorten it to:

sleeper.sleep(deadline.saturating_duration_since(now));

But it feels wasteful* to call sleep when we don't want to sleep, and I would personally have used:

if let Some(time_left) = deadline.checked_duration_since(now) {
    sleeper.sleep(time_left);
}

If someone really want a saturating computation it's not that many extra characters to type deadline.checked_duration_since(now).unwrap_or(Duration::new(0, 0)).

*: Assuming sleeper. means std::thread::, some platforms (Windows and CloudABI from what I can see) don't have any check if the duration is non-zero, and will actually perform the syscall even if the duration is zero.

vi added a commit to vi/rust that referenced this issue Jul 21, 2019
Centril added a commit to Centril/rust that referenced this issue Aug 9, 2019
…, r=alexcrichton

Stabilize checked_duration_since for 1.38.0

Looks like it has already found some use in projects.

Resolves rust-lang#58402.
@alexcrichton
Copy link
Member

Removing nomination since this is covered by #62860

Centril added a commit to Centril/rust that referenced this issue Sep 5, 2019
…, r=Mark-Simulacrum

Stabilize checked_duration_since for 1.38.0

Looks like it has already found some use in projects.

Resolves rust-lang#58402.
Centril added a commit to Centril/rust that referenced this issue Sep 5, 2019
…, r=Mark-Simulacrum

Stabilize checked_duration_since for 1.38.0

Looks like it has already found some use in projects.

Resolves rust-lang#58402.
@bors bors closed this as completed in 843fba3 Sep 5, 2019
Centril added a commit to Centril/rust that referenced this issue Mar 8, 2020
…=Mark-Simulacrum

Clean up unstable book

- rust-lang#58402's feature was renamed to `tidy_test_never_used_anywhere_else` and it is now used for tidy only
- `read_initializer` link is wrong and the doc should be auto-generated so removed
- Add dummy doc for `link_cfg`
- Stop generating `compiler_builtins_lib` doc in favor of b8ccc0f
- Make `rustc_attrs` tracking issue "None"
Centril added a commit to Centril/rust that referenced this issue Mar 8, 2020
…=Mark-Simulacrum

Clean up unstable book

- rust-lang#58402's feature was renamed to `tidy_test_never_used_anywhere_else` and it is now used for tidy only
- `read_initializer` link is wrong and the doc should be auto-generated so removed
- Add dummy doc for `link_cfg`
- Stop generating `compiler_builtins_lib` doc in favor of b8ccc0f
- Make `rustc_attrs` tracking issue "None"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants