The debug assertions can panic on code which has defined behavior in production, but behavior that's probably wrong, and probably would be asserted in productio

The debug assertions can panic on code which has defined behavior in production, but behavior that's probably wrong, and probably would be asserted in production if it weren't too expensive. For example, if you do "u32::INTEGER_MAX + 3" in debug, it will panic, but in production code it will not (and will use the underlying CPU's result of "2") In most scenarios, this is not actually what you want. If your program has the possibility of doing arithmetic near or past the bounds, you should define the semantics you need. I.e., you can use one of saturating_add, wrapping_add, checked_add, or overflowing_add, depending on the semantics that are correct for your application. All of these behave the same between dev and prod.