{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif3jrhbgz7isdgbzkfddqzbi2nxfje4zzmx55ho3fjnvi4sdipndi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mnu3lzgdjzk2"
  },
  "path": "/t/infinite-precision-intermediate-arithmetic-how-much-would-break/24383#post_16",
  "publishedAt": "2026-06-09T09:52:12.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "unchecked",
    "[1]",
    "↩︎"
  ],
  "textContent": "scottmcm:\n\n> In green-field there's a version of this that works great, actually. I don't think it'd be feasible to more Rust's default numerics to doing it, but for something new (or maybe a new type in Rust?) it actually works wonderfully.\n\nFor existing Rust code: Yes, it would break too many things (e.g. if someone relies on wrapping behavior with --release). But I don't think we need or necessarily want a new type for this. It would probably be better to add a block that lets you change the behavior of these operators, that way you can easily switch between them and not need to replace `+` with `*_add` everywhere.\n\nExample:\n\n\n    // Keep the existing behavior (i.e. wrapping in --release, checked in debug builds)\n    a + b * c;\n\n    // A block that allows implicit type changes as long as there are provably no\n    // overflows and it behaves as it would with arbitrary-size integers\n    // (i.e. the behavior proposed in this thread)\n    bikeshed {a + b * c};\n\n    // Explicitly opt-into wrapping in both cases (both do the same thing)\n    a.wrapping_add(b.wrapping_mul(c));\n    wrapping {a + b * c};\n\n    // Saturating\n    a.saturating_add(b.saturating_mul(c));\n    saturating {a + b * c};\n\n    // Checked with result propagation\n    checked {a + b * c}.unwrap(); // checked block returns option\n    // Roughly equivalent to:\n    function foo(a: usize, b: usize, c: usize) -> Option<usize> {\n        a.checked_add(b.checked_mul(c)?)\n    }\n    foo(a,b,c).unwrap()\n\n\nInspiration: unchecked in solidity which removes overflow checks.\n\nWith pattern types (might have been called something else) that'd be like your `Int<MIN, MAX>` but easier to use together with normal integer types. Implementing a separate type would probably be easier than arithmetic mode blocks + (internal) pattern types, but using the existing integer types makes it feel more natural and part of the language. [1]\n\nAnother advantage is that you could if that is desired (for new projects or after careful consideration of all arithmetic) set the default for an entire module/crate. To me being able to specify the behavior of a block of operations feels more useful and flexible for the future than completely separate types or not having AIR in the language entirely (+ it's convenient for things like wrapping behavior).\n\nThose blocks might be possible to do with a macro, but the AIR part (named `bikeshed` above) probably isn't.\n\n* * *\n\n  1. If I remember correctly there was also the proposal to replace/alias the primitives with `Int<MIN,MAX>` as an alternative to pattern types. ↩︎\n\n\n",
  "title": "Infinite precision intermediate arithmetic: how much would break?"
}