{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaddw6ro4el7fr5ygusrem6qvmtekeqdffuizie2qh7vrzdtejsqu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mi6o3zqq36z2"
  },
  "path": "/t/introduce-a-way-to-construct-range-from-start-length/24073?page=2#post_42",
  "publishedAt": "2026-03-28T18:46:33.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The `start .. start + len` syntax is annoying indeed, especially when there's a non-trivial calculation for the start, or just a very long method name.\n\n`[start..][..len]` is okay when the bounds checks get merged and optimized out, but otherwise it leaves _two_ panicking branches in the compiled code (since each panic call has to get its unique argument). `.get(start..)?.get(..len)?` optimizes fine, but that's a lot of punctuation.\n\nThis could be added as a method to `RangeFrom` without being blocked by a new syntax:\n\n\n    (start..).take(len)\n\n\nI wouldn't mind a requirement for the types to be `Copy` or integer-ish. For ranges of string or other complex keys in something like `BTreeMap`, a \"length\" may not make sense anyway.\n\nI wouldn't want it to panic any more than `start + len` does, because it would ruin uses with `.get(start ..+ len)?`. `.get()` already checks for the `start <= len`, but a panic in `..+` would create a redundant check that couldn't be merged together with the one in `.get()`.\n\n`.get(..)` is used specifically to avoid panics from `[..]`, so having another possible panic inserted by `..+` would be an unpleasant surprise.\n\n* * *\n\nVorpal:\n\n> you really should be writing `'a'..'{'`, which is not ideal for human readers\n\nIt seems like there could be plenty more convenience methods, e.g. `('a'..='z').to_exclusive()?`",
  "title": "Introduce a way to construct Range from start + length"
}