{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicwk5ltsh6zmi4qopzc46f4ethocfhif4zd6st5k7np3qkvfbunva",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnsswwrbdal2"
  },
  "path": "/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383#post_9",
  "publishedAt": "2026-06-08T22:40:42.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The research term for this, by the way, is \"AIR model\" (\"as-if infinitely ranged\"). As mentioned, it's much easier to implement for integers than floats, and it would be a good idea to treat them as separate problems. (I also agree that retrofitting it onto Rust today is probably a non-starter—even the behavior of implicitly panicking on overflow is probably depended on by _somebody.)_\n\nI _do_ think allowing mixed-width mixed-signedness comparisons is more viable; Swift managed to pull that one off. Even that can cause confusion sometimes though, for people used to C semantics.\n\n(Alas, \"this is what Lisp and Python\" do is brushing over the hard part. Those languages will implicitly allocate when numbers get big, but they _won't_ panic, saturate, or wrap the result; it just stays as is. Every number in those languages is effectively a bigint, some of them just have optimized representations.)",
  "title": "Infinite precision intermediate arithmetic: how much would break?"
}