{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiflklzgzwilopkbdoe6s4ru7qyctupcz6kwpiza5co3z3enp7rhxy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mns6qeuydgy2"
  },
  "path": "/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383#post_2",
  "publishedAt": "2026-06-08T15:59:00.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "This is, btw, essentially what C does, except the \"infinite\" precision is just to ~~`long`~~ `int`, and narrowing coercions back are implicit.\n\nRealistically, this proposal hinges on the ability of the compiler to prove non-overflow in \"typical uses\", and that would require importing a lot of machinery to the front end from LLVM, be difficult to write a specification for, and would probably fail often enough that people would get massively frustrated when their `i += 1` doesn't work and has to be rewritten as `i = (i + 1).unwrap()` or something. Proving anything about basic arithmetic is, of course, undecidable in the fully general case and NP-complete in somewhat less general cases; the optimizer gets away with it because it works strictly on a best effort basis. But surface language semantics cannot be best-effort.",
  "title": "Infinite precision intermediate arithmetic: how much would break?"
}