|
|
|
|
|
by sshine
2 days ago
|
|
> Given the roughly 30% overhead of overflow checks, I think restricting them to debug builds is a reasonable tradeoff. I can also see an argument for using wrap on overflow even in debug builds for consistency and simplicity. I don’t understand the sentiment to want different behaviour for overflow in debug and release mode. You want to catch overflows because they’re thought of as errors, but not in production. In production you just want silent failure? Rust has a number of specialised integer operations (overflowing, saturating) that are slightly less ergonomic (they’re not literally called ‘+’ etc.). So we’re only really arguing whether we should be safe or performant by default, when we don’t care to be explicit. |
|
There's a lot of safe but slow languages, Rust is trying incredibly hard to be a safe language that is still seen to be in that general C/C++ ballpark of performance.