make it clear that Range cannot represent arbitrary ranges - #162110
Merged
Conversation
RalfJung
added
the
I-libs-nominated
rustbot
added
the
S-waiting-on-review
rustbot
added
the
T-libs
Collaborator
|
r? @nia-e rustbot has assigned @nia-e. Use Why was this reviewer chosen?The reviewer was selected based on:
|
camsteffen
reviewed
Sep 1, 2026
Member
|
Technically |
Member
|
And |
Member
Author
|
With something like #136903, it may actually make a lot of sense to recommend |
clarfonthey
removed
the
I-libs-nominated
Contributor
|
Vibeck from libs meeting was: all good, there are various changes to be made in the future like maybe having a discoverable type alias for One potential addition that could be helpful is clarifying that this only prevents you from including the very last element for a type, and in cases where you know that can't happen (e.g. slice bounds, which are explicitly limited to |
Member
|
@bors r+ |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment was marked as off-topic.
This comment was marked as off-topic.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 1, 2026
make it clear that Range cannot represent arbitrary ranges This seems like a useful clarification, though it is already heavily implied by the first sentence in the docs. What is less clear to me is what type one *should* use to represent arbitrary ranges. Should we recommend `(Bound<T>, Bound<T>)` for that purpose? It seems best-stuied, and is already used for that purpose by the btree collections and in rust-lang#136903. However, I suspect it is also common that one wants to represent an arbitrary range that's bounded on both sides. `RangeInclusive` can represent all those (though representing the empty range is a bit awkward), `Range` cannot. Nominating for t-libs to get their general vibe on what we want to recommend here, if anything.
This was referenced Sep 1, 2026
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 1, 2026
…uwer Rollup of 11 pull requests Successful merges: - #151618 (rustdoc: add `--print` option) - #161287 (Update `icu_list` dependency to 2.3) - #161767 (change DEFAULT_STACK_SIZE to be 32MB on s390x) - #161968 (Diverse offload fixes) - #161971 (Remove -Zsaturating-float-casts flag) - #162071 (Fix ICE of getting item name from RPITIT) - #161209 (Rework `next_power_of_two` to always be `1 << …`) - #162073 (Change some `Infallible` to `!` in std) - #162086 (Remove `gate_check` from `AttributeStability::Unstable`) - #162102 (`alloc` crate: shrink undocumented `unsafe` blocks) - #162110 (make it clear that Range cannot represent arbitrary ranges)
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 1, 2026
Rollup merge of #162110 - RalfJung:range, r=nia-e make it clear that Range cannot represent arbitrary ranges This seems like a useful clarification, though it is already heavily implied by the first sentence in the docs. What is less clear to me is what type one *should* use to represent arbitrary ranges. Should we recommend `(Bound<T>, Bound<T>)` for that purpose? It seems best-stuied, and is already used for that purpose by the btree collections and in #136903. However, I suspect it is also common that one wants to represent an arbitrary range that's bounded on both sides. `RangeInclusive` can represent all those (though representing the empty range is a bit awkward), `Range` cannot. Nominating for t-libs to get their general vibe on what we want to recommend here, if anything.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This seems like a useful clarification, though it is already heavily implied by the first sentence in the docs.
What is less clear to me is what type one should use to represent arbitrary ranges. Should we recommend
(Bound<T>, Bound<T>)for that purpose? It seems best-stuied, and is already used for that purpose by the btree collections and in #136903. However, I suspect it is also common that one wants to represent an arbitrary range that's bounded on both sides.RangeInclusivecan represent all those (though representing the empty range is a bit awkward),Rangecannot.Nominating for t-libs to get their general vibe on what we want to recommend here, if anything.