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

What about catching integer overflow? Free open-source languages still cannot do it unlike they commercial competitors like Swift?

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.

assembly catches integer overflow. You just need to check the flag.

Rust does have checked arithmetic operations (that return Result), but you have to explicitly opt in to them, of course, and they're not as ergonomic to use as regular arithmetic.

But, by default, normal arithmetic operations trap on overflow in debug mode, although they wrap with optimizations on.

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

Ada has had overflow checks for decades:

https://learn.adacore.com/courses/intro-to-ada/chapters/stro...

And there is an Ada implementation that is part of GCC:

https://www.gnu.org/software/gnat/

Rust is the only language I can easily control how integer overflow should behave. I can use `var1.wrapping_add(var2)` if I want the result to be wrapped or `var1.checked_add(var2)` if I don't want it to overflow.

The functions are so verbose and inconvenient that even Rust developers themselves do not use them. For example, in this code [1] they used a wrapping addition instead of "checked_add" because it is faster to write.

For comparison, Swift uses "+" for checked addition and as a result, majority of developers use checked addition by default. And in Rust due to its poor design choices most developers use wrapping addition even where a checked addition should be used.

[1] https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2010

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.

As a result, Rust developers themselves use wrapping addition where a checked addition should be used: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2010

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.

Checked addition by default will have too much overhead and it will hurt performance, which unacceptable in Rust since it was designed as a system language. Swift can use checked add by default since it was designed for application software.

Your example code is not because it is faster to write, it is because it is impossible for its to overflow on that line.

That's not a wrapping addition, that addition will never overflow so it has no overflow behaviour.

This line could only overflow after we need to grow the container, so immediately this means the type T isn't a ZST as the Vec for ZSTs doesn't need storage and so it never grows.

Because its not a ZST the maximum capacity in Rust is never bigger than isize::MAX which is an entire binary order of magnitude smaller than usize::MAX, as a result len + 1 can't overflow the unsigned type, so this code is correct as written.

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.

The reason '+ 1' is fine in the example you gave is that length is always less than or equal to capacity. If you follow 'grow_one' which was earlier in the function to grow the capacity by one if needed, you will find that it leads to the checked addition in [0], which returns an error that [1] catches and turns into a panic. So using '+1' prevents a redundant check in release mode while still adding the check in debug mode in case future code changes break the 'len <= capacity' invariant.

Of course, if you don't trust the standard library, you can turn on overflow checks in release mode too. However, the standard library is well tested and I think most people would appreciate the speed from eliding redundant checks.

  [0]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#651
  [1]: https://doc.rust-lang.org/src/alloc/raw_vec.rs.html#567

Why should checked addition have any overhead? You should just use checked addition instruction (on architectures that support it) instead of wrapping addition.

Or just because on Intel CPUs it has overhead, we must forget about writing safer code?

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