Repository navigation
Tracking Issue for const RangeBounds and const RangeX::contains #108082
Description
Feature gate: #![feature(const_range_bounds)]
This is a tracking issue for making RangeBounds #[const_trait], implementing it for all Range types and allowing range.contains() and associated functions to be called form a const context.
Public API
// core::ops::RangeInclusive
impl<Idx> RangeInclusive<Idx> {
pub const fn into_inner(self) -> (Idx, Idx)
}Steps / History
- Implementation: #...
- Wait for
#![feature(const_trait_impl)]to become stable Tracking issue for closed RFC 2632,impl const Trait for Tyand[const](conditionally const) syntax (const_trait_impl) #67792 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Julia, Robert Serrano Kobylyansky and Felipe S. S. Schneider
Activity
Rollup merge of rust-lang#108084 - ink-feather-org:const_range, r=dto…
RalfJung commentedon Sep 8, 2024
This got mostly removed by #110393, there's just one method left... is that even worth keeping?
RalfJung commentedon Sep 8, 2024
herabit commentedon May 19, 2025
I think it would be useful to at the very least expose the
RangeBoundsfunctionality throughconstinherent methods, particularly onRangeInclusive.Currently there is no way of checking whether the the end bound should be inclusive or exclusive in
const, which makes for implementing accurate reimplementations ofRangeBoundsin stable, that work inconst, difficult.Even if
consttraits aren't available, ever, for types that can expose similar functionality to the traits the implement, inconst, I think they probably should, and just deprecate those inherent methods when, or if they become superseded byconsttraits, if they ever arrive.