Stabilize new inclusive range type and iterator type by pitaj · Pull Request #150522 · rust-lang/rust

pitaj · 2025-12-30T21:07:01Z

Part 1 of stabilizing the new range types for #125687

stabilizes core::range::RangeInclusive and core::range::RangeInclusiveIter. Newly stable API:

// in core and std
pub mod range;

// in core::range

pub struct RangeInclusive<Idx> {
    pub start: Idx,
    pub last: Idx,
}

impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ }

impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> {
    pub const fn contains<U>(&self, item: &U) -> bool
    where
        Idx: [const] PartialOrd<U>,
        U: ?Sized + [const] PartialOrd<Idx>;

    pub const fn is_empty(&self) -> bool
    where
        Idx: [const] PartialOrd;
}

impl<Idx: Step> RangeInclusive<Idx> {
    pub fn iter(&self) -> RangeInclusiveIter<Idx>;
}

impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ }

impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ }
impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ }

pub struct RangeInclusiveIter<A>(/* ... */);

impl<A: Step> RangeInclusiveIter<A> {
    pub fn remainder(self) -> Option<RangeInclusive<A>>;
}

impl<A: Step> Iterator for RangeInclusiveIter<A> {
    type Item = A;
    /* ... */
}

impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ }
impl<A: Step> FusedIterator for RangeInclusiveIter<A> { }
impl<A: Step> IntoIterator for RangeInclusive<A> {
    type Item = A;
    type IntoIter = RangeInclusiveIter<A>;
    /* ... */
}

impl ExactSizeIterator for RangeInclusiveIter<u8> { }
impl ExactSizeIterator for RangeInclusiveIter<i8> { }

unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> {
    type Output = [T];
    /* ... */
}
unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> {
    type Output = str;
    /* ... */
}

I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.

rustbot · 2025-12-30T21:07:06Z

r? @jackh726

rustbot has assigned @jackh726.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

jackh726 · 2025-12-31T01:57:33Z

r? libs-api

library/core/src/range.rs

rustbot · 2026-01-24T01:30:24Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

library/core/src/range.rs

tgross35 · 2026-01-24T01:55:49Z

I added an API summary of what is stabilized here to the top post, nominating for @rust-lang/libs-api to double check and nudge the FCP. There is an ongoing proposed FCP at #125687 (comment), but maybe it makes sense to restart it here with smaller scope?

Everything seems to match up with the traits available on ops::RangeInclusive, delta ExactSizeIterator for i16/u16 (expected as it is incorrect on 16-bit targets).

Two small concerns found from digging around the issue and other discussion:

Stabilize new inclusive range type and iterator type #150522 (comment) is the intent to exclude is_empty for now?
Field names are "start" and "last" which don't typically go together. It used to be "start" and "end" like for Range, but end was renamed at Rename end field of inclusive Range APIs to last libs-team#511 to avoid a footgun. Should we consider start->first so we have "first" and "last"?

@rustbot label +I-libs-api-nominated

scottmcm · 2026-01-24T09:24:42Z

Field names are "start" and "last" which don't typically go together. It used to be "start" and "end" like

TBH, I never thought "start" and "end" went together either. A race is start-to-finish where you place somewhere in first..=last; a story commonly has a beginning, middle, and end.

Are any of those better enough to bother changing something? Dunno.

sendittothenewts · 2026-01-26T11:22:54Z

Should we consider `start`->`first` so we have "first" and "last"?

When I suggested changing end to last on the inclusive ranges, it did occur to me that this would be more consistent. I didn't suggest this change because it would bring Range, RangeFrom and arguably RangeBounds::start_bound into the blast radius for little benefit. Also, there is no first method on iterators to be consistent with.

Amanieu · 2026-01-27T16:51:41Z

We discussed the field names in the @rust-lang/libs-api meeting and were inclined to keep them as they currently are.

pitaj · 2026-01-27T17:25:28Z

As they currently are in this PR, or as they currently are on the old RangeInclusive types?

tgross35 · 2026-01-31T04:17:13Z

As they currently are in this PR, or as they currently are on the old RangeInclusive types?

I believe as they are in this PR. From the meeting notes at https://hackmd.io/_EpeHNVySbqHWCSqXwLX1w#nominated-rusttf150522-Stabilize-new-inclusive-range-type-and-iterator-type

Amanieu: I'm happy with "start" and "last". Any objections?
[...]
Josh: I'd ship the currently proposed API.

And no different names mentioned.

pitaj · 2026-02-07T02:41:14Z

@rustbot ready

I can rebase and squash everything together upon approval

tgross35

FCP completed at #125687 (comment). The basic API is consistent with what is in #125687 (comment) and the few traits not mentioned there match up with existing range types (as I noted at #150522 (comment)). libs-api has also had a chance to talk about this in their meeting so I think everything is all set.

r=me with a squash.

View changes since this review

tgross35 · 2026-02-07T04:18:44Z

@bors delegate+

rust-bors · 2026-02-07T04:18:47Z

✌️ @pitaj, you can now approve this pull request!

If @tgross35 told you to "r=me" after making some further change, then please make that change and post @bors r=tgross35.

stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter` and the `core::range` module

rustbot · 2026-02-07T04:37:28Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

pitaj · 2026-02-07T04:38:56Z

@bors r=tgross35

rust-bors · 2026-02-07T04:38:59Z

📌 Commit d2020fb has been approved by tgross35

It is now in the queue for this repository.

…, r=tgross35 Stabilize new inclusive range type and iterator type Part 1 of stabilizing the new range types for rust-lang#125687 stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API: ```rust // in core and std pub mod range; // in core::range pub struct RangeInclusive<Idx> { pub start: Idx, pub last: Idx, } impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ } impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> { pub const fn contains(&self, item: &U) -> bool where Idx: [const] PartialOrd, U: ?Sized + [const] PartialOrd<Idx>; pub const fn is_empty(&self) -> bool where Idx: [const] PartialOrd; } impl<Idx: Step> RangeInclusive<Idx> { pub fn iter(&self) -> RangeInclusiveIter<Idx>; } impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ } impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ } impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ } impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ } pub struct RangeInclusiveIter<A>(/* ... */); impl<A: Step> RangeInclusiveIter<A> { pub fn remainder(self) -> Option<RangeInclusive<A>>; } impl<A: Step> Iterator for RangeInclusiveIter<A> { type Item = A; /* ... */ } impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ } impl<A: Step> FusedIterator for RangeInclusiveIter<A> { } impl<A: Step> IntoIterator for RangeInclusive<A> { type Item = A; type IntoIter = RangeInclusiveIter<A>; /* ... */ } impl ExactSizeIterator for RangeInclusiveIter<u8> { } impl ExactSizeIterator for RangeInclusiveIter<i8> { } unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> { type Output = [T]; /* ... */ } unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> { type Output = str; /* ... */ } ``` I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.

Rollup of 4 pull requests Successful merges: - #148590 (Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0) - #150522 (Stabilize new inclusive range type and iterator type) - #151576 (Stabilize `core::hint::cold_path`) - #152199 (Move `rustc_query_system::cache`.)

…, r=tgross35 Stabilize new inclusive range type and iterator type Part 1 of stabilizing the new range types for rust-lang#125687 stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API: ```rust // in core and std pub mod range; // in core::range pub struct RangeInclusive<Idx> { pub start: Idx, pub last: Idx, } impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ } impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> { pub const fn contains(&self, item: &U) -> bool where Idx: [const] PartialOrd, U: ?Sized + [const] PartialOrd<Idx>; pub const fn is_empty(&self) -> bool where Idx: [const] PartialOrd; } impl<Idx: Step> RangeInclusive<Idx> { pub fn iter(&self) -> RangeInclusiveIter<Idx>; } impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ } impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ } impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ } impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ } pub struct RangeInclusiveIter<A>(/* ... */); impl<A: Step> RangeInclusiveIter<A> { pub fn remainder(self) -> Option<RangeInclusive<A>>; } impl<A: Step> Iterator for RangeInclusiveIter<A> { type Item = A; /* ... */ } impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ } impl<A: Step> FusedIterator for RangeInclusiveIter<A> { } impl<A: Step> IntoIterator for RangeInclusive<A> { type Item = A; type IntoIter = RangeInclusiveIter<A>; /* ... */ } impl ExactSizeIterator for RangeInclusiveIter<u8> { } impl ExactSizeIterator for RangeInclusiveIter<i8> { } unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> { type Output = [T]; /* ... */ } unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> { type Output = str; /* ... */ } ``` I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.

…uwer Rollup of 8 pull requests Successful merges: - #148590 (Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0) - #150522 (Stabilize new inclusive range type and iterator type) - #152235 (Convert to inline diagnostics in `rustc_parse`) - #152267 (feat: Implement `int_from_ascii` for `NonZero<T>`) - #151576 (Stabilize `core::hint::cold_path`) - #151933 (Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO) - #152010 (Ignore all debuginfo tests for LLDB that we do not run in CI) - #152199 (Move `rustc_query_system::cache`.)

Rollup merge of #150522 - pitaj:stabilize-new-rangeinclusive, r=tgross35 Stabilize new inclusive range type and iterator type Part 1 of stabilizing the new range types for #125687 stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API: ```rust // in core and std pub mod range; // in core::range pub struct RangeInclusive<Idx> { pub start: Idx, pub last: Idx, } impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ } impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> { pub const fn contains(&self, item: &U) -> bool where Idx: [const] PartialOrd, U: ?Sized + [const] PartialOrd<Idx>; pub const fn is_empty(&self) -> bool where Idx: [const] PartialOrd; } impl<Idx: Step> RangeInclusive<Idx> { pub fn iter(&self) -> RangeInclusiveIter<Idx>; } impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ } impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ } impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ } impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ } pub struct RangeInclusiveIter<A>(/* ... */); impl<A: Step> RangeInclusiveIter<A> { pub fn remainder(self) -> Option<RangeInclusive<A>>; } impl<A: Step> Iterator for RangeInclusiveIter<A> { type Item = A; /* ... */ } impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ } impl<A: Step> FusedIterator for RangeInclusiveIter<A> { } impl<A: Step> IntoIterator for RangeInclusive<A> { type Item = A; type IntoIter = RangeInclusiveIter<A>; /* ... */ } impl ExactSizeIterator for RangeInclusiveIter<u8> { } impl ExactSizeIterator for RangeInclusiveIter<i8> { } unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> { type Output = [T]; /* ... */ } unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> { type Output = str; /* ... */ } ``` I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.

rustbot assigned jackh726 Dec 30, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 30, 2025

rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Dec 31, 2025

rustbot assigned BurntSushi and unassigned jackh726 Dec 31, 2025

tgross35 requested changes Jan 24, 2026

View reviewed changes

library/core/src/range.rs Outdated Show resolved Hide resolved

library/core/src/range.rs Show resolved Hide resolved

library/core/src/range.rs Outdated Show resolved Hide resolved

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 24, 2026

tgross35 reviewed Jan 24, 2026

View reviewed changes

library/core/src/range.rs Show resolved Hide resolved

rustbot added the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jan 24, 2026

Amanieu removed the I-libs-api-nominated Nominated for discussion during a libs-api team meeting. label Jan 27, 2026

tgross35 assigned tgross35 and unassigned BurntSushi Jan 31, 2026

This comment has been minimized.

Sign in to view

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 7, 2026

tgross35 approved these changes Feb 7, 2026

View reviewed changes

stabilize new inclusive range type and iter

d2020fb

stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter` and the `core::range` module

pitaj force-pushed the stabilize-new-rangeinclusive branch from f458fc7 to d2020fb Compare February 7, 2026 04:37

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 7, 2026

jhpratt mentioned this pull request Feb 7, 2026

Rollup of 4 pull requests #152266

Closed

This was referenced Feb 7, 2026

Rollup of 9 pull requests #152279

Closed

Rollup of 8 pull requests #152282

Merged

rust-bors bot merged commit 29079e4 into rust-lang:main Feb 7, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Feb 7, 2026

tgross35 mentioned this pull request Feb 9, 2026

Tracking Issue for new_range_api (part of RFC 3550) #125687

Open

15 tasks

Uh oh!

Conversation

pitaj commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 30, 2025

Uh oh!

jackh726 commented Dec 31, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Jan 24, 2026

Uh oh!

Uh oh!

tgross35 commented Jan 24, 2026

Uh oh!

scottmcm commented Jan 24, 2026

Uh oh!

sendittothenewts commented Jan 26, 2026

Uh oh!

Amanieu commented Jan 27, 2026

Uh oh!

pitaj commented Jan 27, 2026

Uh oh!

tgross35 commented Jan 31, 2026

Uh oh!

This comment has been minimized.

pitaj commented Feb 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 commented Feb 7, 2026

Uh oh!

rust-bors bot commented Feb 7, 2026

Uh oh!

rustbot commented Feb 7, 2026

Uh oh!

pitaj commented Feb 7, 2026

Uh oh!

rust-bors bot commented Feb 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

pitaj commented Dec 30, 2025 •

edited

Loading

pitaj commented Feb 7, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading