Matt Godbolt sold me on Rust by showing me C++

I'm not sure if this is what you mean, exactly, but Rust indeed catches this at compile time.

https://play.rust-lang.org/?version=stable&mode=debug&editio... https://play.rust-lang.org/?version=stable&mode=debug&editio...

I meant panic if during any addition (including in runtime) an overflow occurs.

You can set a flag for that: https://doc.rust-lang.org/rustc/codegen-options/index.html#o...

By default, they're on during debug mode and off in release mode.

If you obscure the implementation a bit, you can change GP's example to a runtime overflow [0]. Note that by default the checks will only occur when using the unoptimized development profile. If you want your optimized release build to also have checks, you can put 'overflow-checks = true' in the '[profile.release]' section of your cargo.toml file [1].

  [0]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=847dc401e16fdff14ecf3724a3b15a93
  [1]: https://doc.rust-lang.org/cargo/reference/profiles.html

This is bad because the program behaves different depending on build flags. What's the point of having "use unsafe addition" flag, and having it enabled by default?

Rust developers made a poor choice. They should have made a special function for unchecked addition and have "+" operator always panic on overflow.

The choice doesn't make sense because you want the program to always behave correctly and not only during development.

Why do you want a panic? Shift left. Overflow can be rejected at compile time for a price that you might be able to afford - generality.

Just insist that the programmer prove that overflow can't occur, and reject programs where the programmer couldn't or wouldn't do this.

The point I'm sure was to prevent the checks from incurring runtime overhead in production. Even in release mode, the overflow will only wrap rather than trigger undefined behavior, so this won't cause memory corruption unless you are writing unsafe code that ignores the possibility of overflow.

The checks being on in the debug config means your tests and replications of bug reports will catch overflow if they occur. If you are working on some sensitive application where you can't afford logic bugs from overflows but can afford panics/crashes, you can just turn on checks in release mode.

If you are working on a library which is meant to do something sensible on overflow, you can use the wide variety of member functions such as 'wrapping_add' or 'checked_add' to control what happens on overflow regardless of build configuration.

Finally, if your application can't afford to have logic bugs from overflows and also can't panic, you can use kani [0] to prove that overflow never happens.

All in all, it seems to me like Rust supports a wide variety of use cases pretty nicely.

[0]: https://github.com/model-checking/kani

Eh, maybe. There's a performance tradeoff here and maintainers opted for performance. I'm sure many folks would agree with you that it was the wrong choice, and I'm sure many folks would disagree with you that it was the wrong choice.

There are also specific methods for doing *erflow-checked arithmetic if you like.

Why should there be a performance tradeoff? Because Intel CPU doesn't have add-with-overflow-check instruction, we make our languages less safe?

Programmer has other things to do. Computer or CPU should do the checks.

Actually, the x86 'ADD' instruction automagically sets the 'OF' and 'CF' flags for you for signed and unsigned overflow respectively [0]. So all you need to do to panic would be to follow that with an 'JO' or 'JB' instruction to the panic handling code. This is about as efficient as you could ask for, but a large sequence of arithmetic operations is still going to gum up the branch predictor, resulting in more pipeline stalls.

[0]: https://www.felixcloutier.com/x86/add