Repository: rust
Issue: Slice indexing panics with valid "backwards" ranges
Labels: T-lang,C-discussion

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
use core::ops::Bound;
fn main() {
    let buf: [u32; 0] = [];
    println!("{:?}", &buf[(Bound::Excluded(0), Bound::Included(0))]);
}
```

This feels perfectly valid, since the indices for the start and end of the range are both in-bounds, just with the backwards order that you'd expect. However, Rust internally converts this range into `1..1` and fails:

```
thread 'main' panicked at src/main.rs:4:26:
range end index 1 out of range for slice of length 0
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.85.0-nightly (a4cb3c831 2024-12-17)
binary: rustc
commit-hash: a4cb3c831823d9baa56c3d90514b75b2660116fa
commit-date: 2024-12-17
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/panicking.rs:74:14
   2: core::slice::index::slice_end_index_len_fail_rt
             at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/slice/index.rs:64:5
   3: core::slice::index::slice_end_index_len_fail
             at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/slice/index.rs:58:5
   4: <core::ops::range::Range<usize> as core::slice::index::SliceIndex<[T]>>::index
             at ./.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:465:13
   5: <(core::ops::range::Bound<usize>,core::ops::range::Bound<usize>) as core::slice::index::SliceIndex<[T]>>::index
             at ./.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:1050:9
   6: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at ./.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:16:9
   7: core::array::<impl core::ops::index::Index<I> for [T; N]>::index
             at ./.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/array/mod.rs:375:9
   8: playground::main
             at ./src/main.rs:4:26
   9: core::ops::function::FnOnce::call_once
             at ./.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
```

</p>
</details>

### Reason for emitting these "weird" ranges

I'm trying to create a data structure which stores a series of sorted, disjoint ranges in a `Vec`. When you determine where a provided range might fall into this vec, it's very natural to use the included/excluded bounds: you effectively have a similar API to that of `binary_search`, where "Included" means that an endpoint of a range overlaps with the range stored at an index, and "Excluded" means that the range does not overlap with the range stored at an index, but could be inserted after that index.

In this case, both the "normal" lopsided ranges (inclusive, then exclusive) happen, but also these "backwards" ones with exclusive, then inclusive. So, I think that supporting these "backward" ranges would be nice, even if it complicates the code a bit here.