Repository navigation
Tracking Issue for const_ops #90080
Description
Feature gate: #![feature(const_ops)]
This is a tracking issue for const_ops, which adds const versions of common numeric operations in std::ops.
Public API
NonZeroBitOrBitOrAssignDivRem
WrappingShlShrShlAssignShrAssignAddAddAssignSubSubAssignMulMulAssignDivDivAssignRemRemAssignNotBitXorBitXorAssignBitOrBitOrAssignBitAndBitAndAssignNeg
u*/i*AddSubMulDivRemNegAddAssignSubAssignMulAssignDivAssignRemAssignNotBitAndBitOrBitXorShlShrBitAndAssignBitOrAssignBitXorAssignShlAssignShrAssign
Steps / History
- Implementation: Make most std::ops traits const on numeric types #89876.
- Tests
- Final comment period (FCP)
- Stabilization PR
Unresolved Questions
- None yet.
Activity
AlexApps99 commentedon Nov 3, 2021
Tests need to be implemented for this, I think the files
library/core/tests/{nonzero,num/{int_macros,ops,uint_macros,wrapping}}.rsare good places to start.I should be able to implement them in a week or two, once I can find the time to.
kellerkindt commentedon Jan 22, 2022
FYI: Besides
Wrappingthere also exists aSaturatingtypebenburk commentedon Jun 12, 2022
Any updates or blockers for this feature? Would love to be able to use these in my projects.
AlexApps99 commentedon Jun 12, 2022
I was originally planning to make tests, but I don't think that making any would be useful as it doesn't add any new functionality, and it relies on arithmetic already working in const.
Assuming tests aren't needed, the only other thing would be checking that it's ok to make this trait const. There was some debate when this PR was first made, I'm not sure what the policy is around const traits now.
Mythra commentedon Aug 21, 2022
Hey, sorry to revive this, checking in on any potential updates/blockers. I tried converting some const functions which used
.wrapping_mul,.wrapping_sub, etc. to useWrappingtypes, and it pointed to this issue.AlexApps99 commentedon Aug 21, 2022
Misclick! I can't think of any blockers, since const-ifying these operations doesn't necessitate tests when it uses already-const arithmetic.
It would be good to consult with somebody who can stabilize it, to get their thoughts
TTWNO commentedon Feb 28, 2023
What needs to be done to stabilize this?
I'm looking to use this in tests. Willing to contribute tests, add docs if necessary, but let me know so we can land this.
RalfJung commentedon Sep 8, 2024
This got entirely removed in #110393.
scimind2460 commentedon Jun 25, 2025
Shouldn't this be reopened as
const_opsmay be taken forward by the new syntax proposed by @fee1-dead?RalfJung commentedon Jun 25, 2025
No, if there's a new constification it should get a new tracking issue.
clarfonthey commentedon Jul 8, 2025
It appears that at least for the moment, #67792 and this issue are being used for new const trait impls, rather than them getting their own issues. It's also rather confusing how, despite a lot of work being done to support the "newer" const trait syntax, this old, deprecated issue is still being referenced, with a clarification that we won't open a new issue until the RFC is officially accepted.
Surely, there's a better way to do this? It definitely feels like a bureaucratic game of pretend, where we say we're not working on the new feature until it's accepted even though we are.
clarfonthey commentedon Aug 12, 2025
Since this keeps showing up in my searches, it was replaced by #143802.