Skip to content

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

Description

@gagath

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!

Activity

  1. steveklabnik commented on Sep 8, 2017

    @steveklabnik
    Contributor

    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.

  2. dtolnay commented on Sep 8, 2017

    @dtolnay
    Member

    Adding from_micros sounds okay to me.

  3. sfackler commented on Sep 8, 2017

    @sfackler
    Member

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

  4. added
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    on Sep 17, 2017
  5. added a commit that references this issue on Sep 23, 2017
    24831c7
  6. reopened this on Sep 27, 2017
  7. nagisa commented on Sep 27, 2017

    @nagisa
    Member

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

  8. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    and removed
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    on Sep 27, 2017
  9. SimonSapin commented on Mar 17, 2018

    @SimonSapin
    Contributor

    Looks good to me to stabilize.

    @rfcbot fcp merge

  10. rfcbot commented on Mar 17, 2018

    @rfcbot

    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.

  11. added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Mar 17, 2018
  12. rfcbot commented on Mar 19, 2018

    @rfcbot

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

  13. removed
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    on Mar 19, 2018
  14. rfcbot commented on Mar 29, 2018

    @rfcbot

    The final comment period is now complete.

  15. added a commit that references this issue on Apr 18, 2018
    ac3c228
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE]final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions