| From: David Mason via talk <talk@gtalug.org> | You can turn the checks on, but see this discussion about the default: https://github.com/rust-lang/rust/issues/47739 Thanks. The issue isn't "resolved" so I guess that the default has not been changed. One comment pointed at this which I found fascinating: <https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html> Again, I found that being able to declare variables as being within a range as being very powerful. I admit that the edges get messy: just as requiring arrays to have compile-time bounds is constraining, tight compile-time bounds on integer types is sometimes overly constraining. Of course what we have in most languages is compile-time bounds, but with the hope that they are generous. And usually they are. One could argue that if overflow is rare, we should be able to handle it by falling over to bignums. Unfortunately that adds overhead to every operation -- perhaps JIT compiling techniques could fix that. Maybe a single solution doesn't fit all cases. But silently yielding a wrong answer on overflow is just dangerous. And defining the wrong answer to be correct is not really better. My intuition is that range declaration and checking might actually might be more efficient that simple overflow checking. The compiler would have more actionable information to optimize out checks. After all, most functions are not "partial": the result is well-defined if the parameters conform to their constraints. It's sometimes hard to express those constraints in the type system.