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

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

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

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

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

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`
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: 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