I don't know if Rust will ever attempt to fix this mistake, but I seriously hope they do.
I don't know if Rust will ever attempt to fix this mistake, but I seriously hope they do.
In Rust the standard mandates a guaranteed wrap-around or a controlled crash. The default behavior is crashing in debug mode and wrapping-around in release mode, but you can control that with a compiler flag.
No matter how you look at it, the Rust behavior is safer. The default behavior? Way better in Rust than in C++. Want a guaranteed wrap-around? In Rust, check. In C++, depending on the compiler. Want a guaranteed crash? In Rust, check. In C++, depending on the compiler.
Also worth noting that overflowing has much more severe consequences in C++ than in Rust, due to bounds checks.
> I don't know if Rust will ever attempt to fix this mistake
It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.
> It was discussed many times, and the conclusion is: it is too expensive, and the default will only change if that will change (due to better optimizations and/or better hardware). It is not a mistake, but a conscious decision.
There's also wrapping_add / saturating_add for anyone concerned about this. Ya want a specific behavior? Just tell the compiler! You can also use the type wrappers so it happens implicitly! https://doc.rust-lang.org/std/num/struct.Saturating.html (presumably this is optimizable on hardware that has operators for this, but idk if that happens yet)
That is exactly why Rust's behavior for +/- operators is a mistake and wrong. It should always panic and anyone that wants something different can specify that in code, where it's clear and explicit.
rustc -C overflow-checks=yes
or in your project config, [profile.release]
overflow-checks = true
gives you consistent panics on overflow.