Skip to content
New issue

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

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

Already on GitHub? # 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: An issue tracking the progress of sth. like the implementation of an RFC 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: An issue tracking the progress of sth. like the implementation of an RFC 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"
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC 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