Faster floating point math with Rust's new API

Well, kind of. It's currently documented to wrap in release mode by default, but it's just that - a default. You're free to enable overflow checks in release mode (or disable them in debug if you really like oddball configurations), and either way overflow is considered a logic error that devs shouldn't rely on (and basically can't rely on when not in control of the end binary since it's the end user who controls overflow checks).

The Rust devs are theoretically open to making signed overflow panic by default, but consider such a change unlikely unless "something materially changes" [0].

[0]: https://github.com/rust-lang/rust/issues/47739#issuecomment-...

Rust has two behaviours around overflow. In debug builds, it panics, in release builds it wraps.

IMO wrapping is a reasonable-enough behaviour to avoid UB in release builds, and panicking in debug is definitely the correct behaviour, because you're only avoiding UB by defaulting to something, but that's not nearly enough. In most applications where overflow is a risk you should make sure to choose what behaviour you consider correct.

Thankfully Rust has a pretty robust story around this:

    fn add_behaviour() {
        let small: i32 = 123;
        let big: i32 = i32::MAX;

        assert_eq!(small.wrapping_add(big), i32::MIN + 122);
        assert_eq!(small.overflowing_add(big), (i32::MIN + 122, true));
        assert_eq!(small.overflowing_add(small), (246, false));
        assert_eq!(small.saturating_add(big), i32::MAX);
        assert_panics!(a.strict_add(b)); // (nb: Not a real assertion)

    }

    impl Add for u32 {
        type Output = u32;

        fn add(self, rhs: u32) -> u32 {
            #[cfg(debug_assertions)]
            {
                self.strict_add(rhs)
            }
            #[cfg(not(debug_assertions))]
            {
                self.wrapping_add(rhs)
            }
        }
    }

It's true that since it's safe and faster, release builds default to wrapping rather than panic, but it's still wrong if you overflow any of Rust's default integer types, it's just that in a safe language it won't be Undefined Behaviour.

"I can't be bothered to do it correctly" speaks to the quality of the rest of the product, it's a Brown M&M [read about the Van Halen test if you don't know what a Brown M&M means]

edit - nevermind, I'm wrong lol

They're much stranger than the machine integers. The machine integers are basically like the Integers you were taught in school, except for overflow. That's not nothing but it's a complexity you can ignore entirely so long as you never overflow. In Rust you can have the language keep you safe - if an overflow occurs we'll panic and we're done. However the floating point types are a weird thing entirely invented for the convenience of the machine. They're too often introduced as if, like the machine integers, they're almost familiar numbers from school. Some languages even call these types "real" - but they very much are not actually the Real numbers, not even the approximation that the machine integers were to actual Integers. The programming language can't help you cope today. You can use software like "Herbie" to help you a bit, but today's languages just leave you with it.

https://herbie.uwplse.org/

Here's an easy example you saw in school, a tenth, written 0.1 in decimal. The floating point types cannot represent this number. When you ask for the 32-bit floating point value 0.1 in a language like C or Rust, you actually get exactly 0.100000001490116119384765625 because that was a number the type can represent and it was deemed "close enough".

As for change in semantics, apparently that isn't an issue on JS, Java and .NET JITs in adopting more modern architectures.