Repository navigation
Summary issue for const-stabilizing const_int_overflowing #57237
Description
Activity
Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:
- @Centril
- @Kimundi
- @SimonSapin
- @alexcrichton
- @aturon
- @cramertj
- @dtolnay
- @eddyb
- @joshtriplett
- @nikomatsakis
- @nrc
- @pnkfelix
- @scottmcm
- @sfackler
- @withoutboats
No concerns currently listed.
Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
🔔 This is now entering its final comment period, as per the review above. 🔔
Reacted by Mazdak Farrokhzad and Taylor Cramer
In this issue, I propose that we turn methods gated by
const_int_overflowingintoconst fns on stable. These methods include (for every primitive integer type, i.e.{u,i}{8,16,32,64,128,size}):overflowing_addoverflowing_suboverflowing_muloverflowing_shloverflowing_shrThis proposal depends on #57175 as the above methods use
letbindings.Stabilization won't proceed until #57175 is stabilized.
Since the methods above are pure arithmetic there should be no reason not to eventually make these into
const fns, and since we are gaining that ability, now is as good a time as any.As with other constification proposals for primitive arithmetic (i.e. #57234 and #57105) I've included T-Lang since this affects intrinsics (
add_with_overflow,sub_with_overflow, andmul_with_overflow) and the operational semantics of Rust'sconst fnfragment. This is the last in a series of constification proposals.To avoid depending on 2 other PRs which will inevitably cause merge conflicts I've avoided creating another PR and will instead do so once FCP nears completion.