Skip to content

Tracking issue for integer methods for Wrapping #32463

Open

Description

@SimonSapin

View all comments

u32 and other primitive integer types implement a number of bit-manipulation methods like rotate_left, but Wrapping<_> does not. At the moment this can be worked around with code like Wrapping(x.0.rotate_left(n)) instead of x.rotate_left(n).

It would be nice to implement:

  • count_ones
  • count_zeroes
  • leading_zeroes
  • trailing_zeroes
  • rotate_left
  • rotate_right
  • swap_bytes
  • from_be (?)
  • from_le (?)
  • to_be
  • to_le
  • pow (?)

Edit: Others added after #32463 (comment)

and maybe other methods, for:

  • Wrapping<u8>
  • Wrapping<u16>
  • Wrapping<u32>
  • Wrapping<u64>
  • Wrapping<usize>
  • Wrapping<i8>
  • Wrapping<i16>
  • Wrapping<i32>
  • Wrapping<i64>
  • Wrapping<isize>

Edit: From #50465

  • Decide on correct behavior for wrapping_next_power_of_two

Activity

  1. srinivasreddy commented on Mar 24, 2016

    @srinivasreddy
    Contributor

    I want to take this. Would you review my PR?

  2. SimonSapin commented on Mar 25, 2016

    @SimonSapin
    ContributorAuthor

    I can have a look, but I’m not one of the reviewers who can approve PRs for merging into this repository.

  3. srinivasreddy commented on Mar 25, 2016

    @srinivasreddy
    Contributor

    sure that helps. thanks.

  4. added
    C-feature-acceptedCategory: A feature request that has been accepted pending implementation.
    and removed
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    on Nov 17, 2017
  5. dtolnay commented on Nov 17, 2017

    @dtolnay
    Member

    I would be open to considering a PR that adds these methods.

  6. added a commit that references this issue on Mar 7, 2018
    7e346df
  7. added a commit that references this issue on Mar 10, 2018
    de827e5
  8. added a commit that references this issue on Mar 12, 2018
    4bd0ba4
  9. added a commit that references this issue on Mar 19, 2018
    612c4a9
  10. 25 remaining items

  11. mjbshaw commented on Mar 17, 2021

    @mjbshaw
    Contributor

    Is there still debate around the behavior of wrapping_next_power_of_two? I think that next_power_of_two evaluates to 0 (in release mode) on overflow pretty much requires that wrapping_next_power_of_two does the same; it'd be insanely surprising to behave differently.

    If there is a debate around this, how can I get involved to push for stabilization?

  12. added a commit that references this issue on May 13, 2021
  13. gendx commented on Jul 21, 2023

    @gendx
    Contributor

    Seconding @briansmith 's comment from soon 5 years ago, is there anything blocking stabilization of the basic and uncontroversial methods like rotate_left|right, count_zeroes|ones, etc.?

    It doesn't seem to me that requiring the nightly compiler is justified for trivial 1-line methods that have been around for many years now.

    Given the lack of discussion here, can one directly send a PR to stabilize some methods?

  14. dlight commented on May 27, 2024

    @dlight

    How can this be driven forward? Right now Wrapping is less useful than it should be.

    Given the lack of discussion here, can one directly send a PR to stabilize some methods?

    I hope so!

  15. bjoernager commented on Feb 24, 2025

    @bjoernager
    Contributor

    Would it make sense to make this also include the recently-stabilised cast_unsigned and cast_signed (tracking issue #125882)?

  16. Pr0methean commented on Jan 11, 2026

    @Pr0methean

    Could Wrapping please also implement From<T> and From<Wrapping<T>> for all the integer types? x.0 as for narrowing isn't as readable, and it makes tools complain about the overflow.

  17. Apersoma commented on Apr 17, 2026

    @Apersoma
    Contributor

    Could we also get the get function that NonZero has so that macros could take either?

  18. 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
  19. added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    and removed
    Libs-SmallLibs issues that are considered "small" or self-contained
    on Oct 7, 2026
  20. added
    S-tracking-partial-stabilizationStatus: Part of this tracking issue was stabilized, and should be split into separate issues.
    on Nov 4, 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

    B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.I-libs-radarLibs issues that are tracked on the team's radar.S-tracking-partial-stabilizationStatus: Part of this tracking issue was stabilized, and should be split into separate issues.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