I heard that Swift catches the overflow (and underflow). Rust also does that, but only in debug builds. So now we're finally seeing the mainstream languages adopt the integer-overflow-as-an-exception approach.
Rust had used unbounded integer literals by default for some time, so `let a = 1` was an error unless the type could be inferred otherwise. But it was abandoned as it caused some ergonomic problems. Now the integer literals without a suffix are considered `i32`. Given the overflow is catched in runtime, I believe this is a good compromise between the two extremes.
Certainly trapping overflow is progress, but it's not that hard to implement unbounded integers such that the common case (small integers) are just as efficient as the modulo arithmetic we use today.
Sun's SPARC even included hardware support for this (TADDcc, TSUBcc), but programming languages didn't exploit it and the support was removed.
This will only change once there's enough demand that supporting it in hardware becomes a competitive advantage. There's plenty of precedence for this, eg. various crypto support in x86, the evolution of GPUs, networking accelerators, etc.
I intend to change Reduceron to use unbounded integers by default so that the promise that "Well typed programs don't go wrong" isn't a blatant lie.
Rust had used unbounded integer literals by default for some time, so `let a = 1` was an error unless the type could be inferred otherwise. But it was abandoned as it caused some ergonomic problems. Now the integer literals without a suffix are considered `i32`. Given the overflow is catched in runtime, I believe this is a good compromise between the two extremes.