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. 24 remaining items

  11. scottmcm commented on Nov 24, 2020

    @scottmcm
    Member

    ... to be zero on overflow

    Note that next_power_of_two is already stable as wrapping to 0 in release mode, so I think it would be very surprising for wrapping_next_power_of_two to do anything different. (Regardless of which answer is actually better.)

    ... to obtain the bitmask of ...

    If people want that, I would encourage them to propose it as a separate method. It's nicer than next_power_of_two since it has no overflow hazards, so doesn't need the full checked/wrapping/saturating set.

    Strawman for a bikeshed: fill_lower_bits.

  12. 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?

  13. added a commit that references this issue on May 13, 2021
  14. 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?

  15. 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!

  16. 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)?

  17. 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.

  18. Apersoma commented on Apr 17, 2026

    @Apersoma
    Contributor

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

  19. 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
  20. 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
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.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