{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreic6lkz3eebxk7qeppecmywozroqqcq6y4hrovkvirjlbsnehgndsy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnsfgo4ogt42"
  },
  "path": "/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383#post_7",
  "publishedAt": "2026-06-08T18:08:34.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The intermediate representation has to be infinite-precision for something like this to work correctly. (And it is much easier to implement with ints than with floats.)\n\nI do think this is generally the correct approach to take, because it's both easy to use as a programmer and means you reliably get an error when overflow isn't handled correctly. However, there are a lot of cases that make it hard for a compiler to reason about. For example:\n\n\n    fn count_odd_elements(slice: &[usize]) -> usize {\n        let mut count = 0;\n        for element in slice { count += element % 2; }\n        count\n    }\n\n\nHere, `count` cannot overflow because the length of the slice (and thus the number of loop iterations) is less than `usize::MAX`. But proving the lack of overflow requires reasoning about the code as a whole – the `count += element % 2;` line could potentially overflow if `count` were initialized to a higher value.\n\nThis makes me think that it would be very hard to retrofit an approach like this onto Rust: you would probably need to bake the reasoning about integer ranges into the entire language.",
  "title": "Infinite precision intermediate arithmetic: how much would break?"
}