Skip to content

Tracking Issue for Duration::from_nanos_u128 #139201

Closed

Description

@RalfJung

Feature gate: #![feature(duration_from_nanos_u128)]

This is a tracking issue for Duration::from_nanos_u128. See the ACP at rust-lang/libs-team#567.

Public API

// std::time

impl Duration {
    /// Creates a new Duration from the specified number of nanoseconds.
    ///
    /// # Panics
    ///
    /// Panics if the given number of nanoseconds overflows the Duration size.
    pub const fn from_nanos_u128(nanos: u128) -> Duration;
}

Steps / History

Unresolved Questions

  • Is this the best name we can come up with?
  • Should we instead try to generalize from_nanos with a sealed trait? That would block this on const traits.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libs-api[DEPRECATED; DO NOT USE]
    on Apr 1, 2025
  2. added a commit that references this issue on Apr 2, 2025
  3. added a commit that references this issue on Apr 11, 2025
  4. clarfonthey commented on May 31, 2025

    @clarfonthey
    Contributor

    It would be a bit unprecedented and require const traits, but it feels like the most ideal way to do this would be to use a sealed trait to allow calling this method with both u128 and u64. That way, backwards compatibility isn't broken, but we don't need to settle for a weird, unintuitive combination of methods.

    I know that this sort of change can break inference, but I know such breakages are allowed as "non-breaking" changes and there probably wouldn't be a massive impact here.

    (note: const traits are only required since the method is already stably const)

  5. added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    E-help-wantedCall for participation: Help is requested to fix this issue.
    on Aug 27, 2025
  6. tgross35 commented on Aug 27, 2025

    @tgross35
    Member

    Labeling help wanted: there is a PR at #139243, but @omanirudh requested that somebody else take over #139243 (comment). It should be pretty straightforward to get this over the line: for anybody interested, start with that PR as a base and address the review comments that haven't yet been resolved.

    (@omanirudh feel free to correct this if you are still interested in continuing)

  7. added a commit that references this issue on Aug 30, 2025
  8. added a commit that references this issue on Aug 30, 2025
  9. added a commit that references this issue on Sep 9, 2025
  10. removed
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    on Sep 9, 2025
  11. 20 remaining items

  12. added a commit that references this issue on Nov 13, 2025
  13. added a commit that references this issue on Nov 13, 2025
  14. added this to the 1.93.0 milestone on Nov 20, 2025
  15. added a commit that references this issue on Nov 30, 2025
  16. added a commit that references this issue on Dec 10, 2025
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

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-ready-to-stabilizeStatus: This is ready to stabilize; it may need a stabilization report and a PRT-libs-api[DEPRECATED; DO NOT USE]disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions