Tracking Issue for const_ops

[RalfJung]

Feature gate: #![feature(const_ops)]

This is a tracking issue for const-stability of traits in ops.

Public API

// core::ops

#[const_trait]
pub trait Add<Rhs = Self> { ... }

#[const_trait]
pub trait Sub<Rhs = Self> { ... }

#[const_trait]
pub trait Mul<Rhs = Self> { ... }

#[const_trait]
pub trait Div<Rhs = Self> { ... }

#[const_trait]
pub trait Rem<Rhs = Self> { ... }

• Neg
• Not
• BitAnd
• BitOr
• BitXor
• Shl
• Shr
• AddAssign
• SubAssign
• MulAssign
• DivAssign
• RemAssign
• BitAndAssign
• BitOrAssign
• BitXorAssign
• ShlAssign
• ShrAssign

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation:
  • Make Sub, Mul, Div and Rem const_traits #143000
  • Add const Rem #143040
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions / Blockers

• Blocked on Tracking Issue for RFC 3762, "Make trait methods callable in const contexts" #143874

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[clarfonthey]

Gonna tackle making the rest of the relevant traits in core::ops const. Previously, I was going to split this into const_arith_ops and const_bit_ops, but per recommendation, I've un-split them, meaning that no split is going to happen.

EDIT: Will include a full list of changes in attached PR, but it's worth noting the relevant traits that will be added to this tracking issue:

• Neg
• Not
• BitAnd
• BitOr
• BitXor
• Shl
• Shr
• AddAssign
• SubAssign
• MulAssign
• DivAssign
• RemAssign
• BitAndAssign
• BitOrAssign
• BitXorAssign
• ShlAssign
• ShrAssign

Additionally, besides the current implementations for primitives, it will include implementations for Duration, Ipv[46]Addr, references of primitives, Wrapping, and Saturating, since all of those implementations depend on already-const-stable methods and just needed to be marked const with the appropriate stability attribute.

In particular, I suspect that the Assign variants were omitted back when these traits were originally constified because mutable references weren't stable in const context yet, but they now are, so, there's no reason to not include them as well since most of them are just simple *self = *self op rhs impls anyway.

[fee1-dead]

Previously, I was going to split this into const_arith_ops and const_bit_ops, but per recommendation, I've un-split them, meaning that no split is going to happen.

I don't think a split is necessary here. I think if we were to stablize it we'd likely stabilize them altogether.