Skip to content

Consider adding a from_micros for std::time::Duration #44400

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

Closed
gagath opened this issue Sep 7, 2017 · 8 comments · Fixed by #44436
Closed

Consider adding a from_micros for std::time::Duration #44400

gagath opened this issue Sep 7, 2017 · 8 comments · Fixed by #44436
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 final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@gagath
Copy link
Contributor

gagath commented Sep 7, 2017

During the write of an embedded library I needed to make a pause of 10 microseconds. Looking over the Nightly std::time::Duration documentation page I understood that I had to use the following construction:

// Wait 10 microseconds
thread::sleep(Duration::new(0, 10_000));

The sad part is that this is less clear to me than Duration::from_micros(10). Currently the from_millis and from_secs functions are implemented but not from_micros which could help write cleaner code IMO.

The fix seems pretty easy, maybe if you judge this useful I can try to write my first pull request to the Rust project!

@steveklabnik
Copy link
Member

The fix seems pretty easy, maybe if you judge this useful I can try to write my first pull request to the Rust project!

In general, this is how @rust-lang/libs works; small additions can just be a PR, larger additions need an RFC. So, I'd suggest that you send in a PR implementing this.

@dtolnay
Copy link
Member

dtolnay commented Sep 8, 2017

Adding from_micros sounds okay to me.

@sfackler
Copy link
Member

sfackler commented Sep 8, 2017

Yeah, I'd be on board with a PR.

@frewsxcv frewsxcv added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 13, 2017
@TimNN TimNN added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Sep 17, 2017
bors added a commit that referenced this issue Sep 23, 2017
Add Duration::from_micros

This fixes #44400 that explains why it could be useful for embedded designs timing.
@nagisa nagisa reopened this Sep 27, 2017
@nagisa
Copy link
Member

nagisa commented Sep 27, 2017

This is now a tracking issue for the function added in the previously referenced PR.

@nagisa nagisa 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 Sep 27, 2017
@SimonSapin
Copy link
Contributor

Looks good to me to stabilize.

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Mar 17, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), 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 this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 17, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 19, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 19, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 29, 2018

The final comment period is now complete.

bors added a commit that referenced this issue Apr 18, 2018
stabilize a bunch of minor api additions

besides `ptr::NonNull::cast` (which is 4 days away from end of FCP) all of these have been finished with FCP for a few weeks now with minimal issues raised

* Closes #41020
* Closes #42818
* Closes #44030
* Closes #44400
* Closes #46507
* Closes #47653
* Closes #46344

the following functions will be stabilized in 1.27:
* `[T]::rsplit`
* `[T]::rsplit_mut`
* `[T]::swap_with_slice`
* `ptr::swap_nonoverlapping`
* `NonNull::cast`
* `Duration::from_micros`
* `Duration::from_nanos`
* `Duration::subsec_millis`
* `Duration::subsec_micros`
* `HashMap::remove_entry`
# 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 final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. 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.

9 participants