Open
Description
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)
is_power_of_two
(?)next_power_of_two
(?)min_value
(?)max_value
(?)from_str_radix
(?)reverse_bits
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
Metadata
Metadata
Assignees
Labels
Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are considered "small" or self-containedLibs issues that are tracked on the team's project board.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
srinivasreddy commentedon Mar 24, 2016
I want to take this. Would you review my PR?
SimonSapin commentedon Mar 25, 2016
I can have a look, but I’m not one of the reviewers who can approve PRs for merging into this repository.
srinivasreddy commentedon Mar 25, 2016
sure that helps. thanks.
dtolnay commentedon Nov 17, 2017
I would be open to considering a PR that adds these methods.
Impl Integer methods for Wrapping
Rollup merge of rust-lang#48810 - Phlosioneer:32463-impl-integer-for-…
Rollup merge of rust-lang#48810 - Phlosioneer:32463-impl-integer-for-…
28 remaining items
JohnBSmith commentedon Nov 24, 2020
There is a further argument for
wrapping_next_power_of_two
to be zero on overflow. One might useto obtain the bitmask of all numbers in
0..m
.scottmcm commentedon Nov 24, 2020
Note that
next_power_of_two
is already stable as wrapping to0
in release mode, so I think it would be very surprising forwrapping_next_power_of_two
to do anything different. (Regardless of which answer is actually better.)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
.mjbshaw commentedon Mar 17, 2021
Is there still debate around the behavior of
wrapping_next_power_of_two
? I think thatnext_power_of_two
evaluates to 0 (in release mode) on overflow pretty much requires thatwrapping_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?
Rollup merge of rust-lang#85177 - tspiteri:wrapping-bits, r=joshtriplett
Saturating
type #87920core::ops::*<T>
onSaturating<T>
/Wrapping<T>
type #91586gendx commentedon Jul 21, 2023
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?
dlight commentedon May 27, 2024
How can this be driven forward? Right now
Wrapping
is less useful than it should be.I hope so!
bjoernager commentedon Feb 24, 2025
Would it make sense to make this also include the recently-stabilised
cast_unsigned
andcast_signed
(tracking issue #125882)?