{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif4lfoooeygztclreorc7vvntrhjnbtqtwu57p5you3jahns2ow3a",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3miacaw3pgi32"
  },
  "path": "/t/introduce-a-way-to-construct-range-from-start-length/24073?page=3#post_44",
  "publishedAt": "2026-03-29T22:32:50.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "playground"
  ],
  "textContent": "Vorpal:\n\n> I know that in general using inclusive ranges are slower than exclusive ranges, since the type needs to keep track of if it reached the end separately (in case the ending value is one that would overflow).\n>\n> However, I don't know if rustc can optimise this when the range is known at compile time to not overflow.\n\nThe two loops in this function...\n\n\n    pub fn main() {\n        for i in 0..=26 {\n            println!(\"{i}\")\n        }\n        for i in 0..27 {\n            println!(\"{i}\")\n        }\n    }\n\n\n... do not compile to the same assembly code (playground) so clearly there is still at least some work to be done. (I find LLVM's choice of fully unrolling the second loop questionable on code size grounds, but just the fact that it did that _only_ for the second loop indicates that its understanding of the first loop is probably weaker.)",
  "title": "Introduce a way to construct Range from start + length"
}