Skip to content

Tracking Issue for integer extension and truncation methods #154330

Open
Open
Tracking Issue for integer extension and truncation methods#154330
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-needs-to-bakeStatus: The implementation is "complete" but it needs time to bake.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Description

@Amanieu
Amanieu
opened on Mar 24, 2026

View all comments

Feature gate: #![feature(integer_extend_truncate)]

This is a tracking issue for integer extension and truncation methods.

Public API

impl iX {
    // `Target` is a signed integer with size >= Self
    fn widen<Target>(self) -> Target
        where Self: WidenTarget<Target>;

    // `Target` is a signed integer with size <= Self
    fn truncate<Target>(self) -> Target
        where Self: TruncateTarget<Target>;
    fn saturating_truncate<Target>(self) -> Target
        where Self: TruncateTarget<Target>;
    fn checked_truncate<Target>(self) -> Option<Target>
        where Self: TruncateTarget<Target>;
}

impl uX {
    // `Target` is an unsigned integer with size >= Self
    fn widen<Target>(self) -> Target
        where Self: WidenTarget<Target>;

    // `Target` is an unsigned integer with size <= Self
    fn truncate<Target>(self) -> Target
        where Self: TruncateTarget<Target>;
    fn saturating_truncate<Target>(self) -> Target
        where Self: TruncateTarget<Target>;
    fn checked_truncate<Target>(self) -> Option<Target>
        where Self: TruncateTarget<Target>;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

Unresolved Questions

  • None yet.

Footnotes

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

Activity

  1. Amanieu
    added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    S-tracking-unimplementedStatus: The feature has not been implemented.
    on Mar 24, 2026

  2. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026 · Hidden as resolved

  3. Amanieu commented on Mar 24, 2026

    @Amanieu
    Amanieu
    on Mar 24, 2026 · Hidden as resolved
    Author

  4. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026 · Hidden as resolved

  5. tgross35 commented on Mar 24, 2026

    @tgross35
    tgross35
    on Mar 24, 2026
    Member

    Is there any reason not to include widening unsigned->signed conversions as part of ExtendTarget? E.g. u8 to i16 is lossless.

  6. joshtriplett commented on Mar 24, 2026

    @joshtriplett
    joshtriplett
    on Mar 24, 2026
    Member

    Is there any reason not to include widening unsigned->signed conversions as part of ExtendTarget? E.g. u8 to i16 is lossless.

    We discussed this in the @rust-lang/libs-api meeting, and felt that either code should write these as separate conversions (e.g. .extend().cast_signed()) or use .into() which already provides "conversion via multiple operations at once".

  7. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026
    Member

    Not doing so ensures the methods serve exactly one purpose. It's trivial to chain that and .cast_signed() (already stable) in that situation. Imo it's more explicit about what is happening.

    Last I checked, time is the only code base using num-conv, so check that out if you want to see real world code. Otherwise it's just examples, realistically.

  8. joshtriplett commented on Mar 24, 2026

    @joshtriplett
    joshtriplett
    on Mar 24, 2026 · Hidden as resolved

  9. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026 · Hidden as resolved

  10. joshtriplett commented on Mar 24, 2026

    @joshtriplett
    joshtriplett
    on Mar 24, 2026 · Hidden as resolved

  11. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026 · Hidden as resolved

  12. joshtriplett commented on Mar 24, 2026

    @joshtriplett
    joshtriplett
    on Mar 24, 2026 · Hidden as resolved

  13. jhpratt commented on Mar 24, 2026

    @jhpratt
    jhpratt
    on Mar 24, 2026 · Hidden as resolved

  14. 13 remaining items

  15. joshtriplett commented on May 4, 2026

    @joshtriplett
    joshtriplett
    on May 4, 2026
    Member

    @Qelxiros That would be nice, with clippy's usual mechanism for only issuing such lints if your MSRV allows it.

  16. bjoernager commented on May 4, 2026

    @bjoernager
    bjoernager
    on May 4, 2026
    Contributor

    Has the name widen been discussed instead of extend? Keeping in mind widening_mul having similar functionality (now that it's to return a wider integer.)

  17. joshtriplett commented on May 7, 2026

    @joshtriplett
    joshtriplett
    on May 7, 2026
    Member

    @bjoernager That's a really good thought. widen would be more consistent, and would avoid conflicts with the meaning of extend in collections. Big 👍 to changing that. Nominating to discuss.

  18. joshtriplett
    added
    I-libs-api-nominated[DEPRECATED; DO NOT USE]
    on May 7, 2026

  19. joshtriplett commented on May 8, 2026

    @joshtriplett
    joshtriplett
    on May 8, 2026
    Member

    #156298

  20. Amanieu commented on May 12, 2026

    @Amanieu
    Amanieu
    on May 12, 2026
    MemberAuthor

    If we adopt widen then for symmetry we should also rename the truncating operations to narrow. Proposed names:

    • truncating_narrow
    • saturating_narrow
    • checked_narrow

    And possibly even an unchecked_narrow which is UB if the original value doesn't fit in the narrowed type.

  21. SimonSapin commented on May 12, 2026

    @SimonSapin
    SimonSapin
    on May 12, 2026
    Contributor

    is there any architecture with instructions for unchecked_narrow with some advantage over truncating_narrow?

  22. Qelxiros commented on May 12, 2026

    @Qelxiros
    Qelxiros
    on May 12, 2026
    Contributor

    I'd guess that truncating_narrow is a bitmask of some sort, while the caller of unchecked_narrow must guarantee that value already fits in the smaller size, so it can be a no-op (assuming the value lives in a register at that program point). I'm not 100% sure though.

  23. programmerjake commented on May 12, 2026

    @programmerjake
    programmerjake
    on May 12, 2026
    Member

    unchecked_narrow improves optimizations since it tells LLVM the input is in range so if LLVM needs to widen the values to fit in registers it needs no explicit conversion and probably other optimizations too.

  24. jhpratt commented on May 18, 2026

    @jhpratt
    jhpratt
    on May 18, 2026
    Member

    Updated num-conv with widen. I'm also now subscribed to this issue since apparently I wasn't before.

  25. asquared31415 commented on May 26, 2026

    @asquared31415
    asquared31415
    on May 26, 2026
    Contributor

    "truncate" and "extend" are well known terms that have been used for decades to describe this specific operation, is there a reason that the libs team prefers the new names?

  26. nia-e
    removed
    I-libs-api-nominated[DEPRECATED; DO NOT USE]
    on Jun 2, 2026

  27. joshtriplett commented on Jul 28, 2026

    @joshtriplett
    joshtriplett
    on Jul 28, 2026
    Member

    @asquared31415 One reason is that we already have extend methods in the standard library that means something else (adding items to a collection).

  28. clarfonthey
    added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
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-needs-to-bakeStatus: The implementation is "complete" but it needs time to bake.T-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions