Rust thread asks what would break with infinite-precision arithmetic

zackw’s Rust Internals prompt looks like a math exercise until you notice what it is really poking at: the meaning of ordinary Rust expressions. The June 8, 2026 post asked what would happen if arithmetic were evaluated as if it lived in the reals, or even the complexes when needed, with the final machine type chosen only at the end. By June 14, the thread had already pulled in 26 replies and 956 views, which is about right for a question that sounds abstract but reaches straight into the code Rust users write every day.

A stress test for the language, not a math puzzle

The provocative part is not the idea of exact arithmetic itself, but the place where it would sit in the pipeline. Today, intermediate values in Rust expressions already carry the machine-width meaning of the types you wrote, so overflow, truncation, and shifting are not just end results, they are part of the expression’s behavior as it runs. In zackw’s thought experiment, widening conversions would disappear from the center of the expression, and operators like division and shifts would produce the mathematically correct result before any final type was chosen.

That sounds tidy until you start tracing the knock-on effects. If `3 / 2` were carried as an exact 1.5 in the middle instead of becoming an integer right away, or if `1 << 8` were not immediately bound to a `u8` or `u32` interpretation, then a lot of Rust code would stop behaving like the author expected. The proposal is interesting precisely because it changes the meaning of intermediate values, not just the final cast.

Overflow-dependent logic is the first pressure point

Rust already splits arithmetic behavior by build mode and flags. In debug mode, integer operators panic on overflow. In release builds, Rust typically uses two’s-complement wrapping unless overflow checks are enabled. Cargo’s release profiles disable overflow checks by default, and the Reference points to `-C overflow-checks` and `-C debug-assertions` as the direct switches that control the behavior.

That means plenty of code quietly depends on wraparound or on an overflow trap appearing at a specific point. A counter like this is a classic example:

let next = count + 1; if next == 0 { reset(); }

That logic makes sense only if `count + 1` can roll over in the type you are using. Under an exact-intermediate model, the middle of the expression no longer looks like a machine integer at all, so the place where wraparound used to matter would move, or vanish, or turn into a final cast problem instead. The Rust standard library provides explicit tools for that reason, including `wrapping_add` and the `Wrapping<T>` newtype, and RFC 560 argued that source code should not rely on wrapping semantics in the first place.

Const-eval would stop being a side issue

Constant evaluation is where the proposal becomes even more disruptive. The Rust Reference says that in `const` contexts, overflow is a compile-time error if the expression must be evaluated at compile time. Rust 1.45.0, released on July 16, 2020, made that boundary more visible by tightening compile-time overflow behavior that had previously slipped through in some cases.

So a constant like this today is not just a runtime question:

const BYTES: u8 = 250 + 10;

If the expression must be evaluated at compile time, overflow is an error. An exact-intermediate model would move that decision point. The arithmetic might reach 260 before any final type was chosen, which means the compiler would have to decide whether the final `u8` cast is part of the same error check or a separate one. That is not a cosmetic change. It alters when the compiler rejects code, which in turn alters how people write `const` values, array lengths, masks, and other compile-time numeric plumbing.

Literal inference would get less obvious, not more

Rust’s integer literals are already flexible, but they are not free-floating forever. Context usually pins them down, and mixed-width expressions lean on that machinery. Infinite-precision intermediates would push that pressure deeper into the expression tree, because the compiler would have to preserve exactness longer before choosing a concrete type.

A tiny expression like `let x = 1 + 255;` looks harmless, but the moment it lives inside a narrower target type, the compiler has to reconcile an exact middle with a finite edge. That matters for `let n: u8 = 1 + 255;`, but it also matters for expression chains where the chosen type is inferred from surrounding code. The breakage zone is not just “overflow happened.” It is “the language stopped letting the middle of the expression behave like the type at the edge.”

Optimizer assumptions would need a fresh contract

There is also a quieter cost: the optimizer. Rust’s current numeric rules give the compiler a clear contract about when arithmetic can panic, wrap, or be checked, and those guarantees affect what transformations are safe. If intermediate results became exact and only later collapsed to a machine type, then the optimizer would have to treat the middle of many expressions as semantically wider than the final storage type.

That matters for code that branches on arithmetic outcomes, hoists calculations, or relies on the current wrap or panic behavior being stable enough to reason about. A change like this would not just touch parser or type-checker trivia. It would force a rethink of how the compiler proves that numeric rewrites still preserve meaning.

Why the thread keeps landing on old questions

This is not the first time Rust has had to argue about overflow. RFC 560 laid down the long-running policy that Rust source should not depend on wrapping semantics and should be written as if overflow checking might be enabled. A 2021 Rust Internals discussion even proposed switching the default overflow-checking behavior, which shows that the safety-versus-performance tradeoff is still active rather than settled.

That is why the infinite-precision idea is such a useful stress test. It exposes the quiet assumption that the number in your head and the number in the machine are already the same thing once the expression starts. Rust does not actually promise that, and this thread makes the gap impossible to ignore.