use sign variable in abs and wrapping_abs methods
#64386
Conversation
rust-highfive
added
the
S-waiting-on-review
tspiteri
force-pushed
the
const-abs2
branch
from
cc8222e
to
fa7c6c4
Compare
src/libcore/num/mod.rs
Outdated
| @@ -1402,7 +1402,16 @@ $EndFeature, " | |||
| #[stable(feature = "no_panic_abs", since = "1.13.0")] | |||
| #[inline] | |||
| pub const fn wrapping_abs(self) -> Self { | |||
| (self ^ (self >> ($BITS - 1))).wrapping_sub(self >> ($BITS - 1)) | |||
| // sign is -1 (all ones) for -ve numbers, 0 otherwise. | |||
There was a problem hiding this comment.
Thanks for adding comments! However, please spell out "negative" and "positive", these abbreviations are fairly hard to decipher.
(That said, this does not really alleviate my concern about sacrificing code readability to please const qualification.)
There was a problem hiding this comment.
I removed the abbreviations.
About readability, I do not share your concern. While, all other things being equal, simpler code is better, I don't think it is enough reason to delay better functionality, specifically I don't think it is enough reason to delay making the abs functions const until the time when const support in the compiler improves. I also think having this functionality in the standard library is helpful as it avoids having such tricks repeated in user code, where it is more probable that typos get in somewhere.
And in this case the normal issues with less obvious code are not so problematic in my opinion: Modifiability is not such an issue, because there is very little scope for modifying the abs functions. And the risk of getting incorrect behaviour is extremely tiny (I want to say there is no risk in this case, but there's always the remote chance that this change triggers some hidden bug in some other part of the compiler, so I'll stay with extremely tiny ☺).
The comments help as they make it possible (though not necessarily trivial) for even someone with a very limited knowledge of two's-complement representation and bitwise manipulation to verify the correctness of the code.
This also makes the code easier to understand by hinting at the significance of `self >> ($BITS - 1)` and by including an explanation in the comments. Also, now overflowing_abs simply uses wrapping_abs, which is clearer and avoids a potential performance regression in the LLVM IR.
tspiteri
force-pushed
the
const-abs2
branch
from
fa7c6c4
to
562903a
Compare
|
Ping from triage. @eddyb any updates on this? Thanks. |
|
@bors r+ we can get readability back once we have if/match in const fn |
|
📌 Commit 562903a has been approved by |
bors
added
S-waiting-on-bors
|
r? @oli-obk |
use `sign` variable in abs and wrapping_abs methods This also makes the code easier to understand by hinting at the significance of `self >> ($BITS - 1)`. Also, now `overflowing_abs` simply uses `wrapping_abs`, which is clearer and avoids a potential performance regression in the LLVM IR. This PR follows from the discussion from rust-lang#63786. r? @eddyb cc @nikic
Rollup of 6 pull requests Successful merges: - #62975 (Almost fully deprecate hir::map::Map.hir_to_node_id) - #64386 (use `sign` variable in abs and wrapping_abs methods) - #64508 (or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR) - #64738 (Add const-eval support for SIMD types, insert, and extract) - #64759 (Refactor mbe a tiny bit) - #64764 (Master is now 1.40 ) Failed merges: r? @ghost
This also makes the code easier to understand by hinting at the significance of
self >> ($BITS - 1).Also, now
overflowing_abssimply useswrapping_abs, which is clearer and avoids a potential performance regression in the LLVM IR.This PR follows from the discussion from #63786.
r? @eddyb
cc @nikic