Ideally CPU's would have hardware traps for integer overflow, but in practice no mainstream architectures do. Integer overflow can cause all kinds of weird problems. Additionally, Java simplifies over C/C++ by having only one kind of integer (signed) but at the cost of making it harder to write code that has to work with unsigned amounts. This comes up a lot when dealing with binary file formats and networking protocols.
When I think about the worst bugs that I’ve written/encountered in recent years, lack of unsigned types and unexpected integer overflows crop up a lot because they can lead to silent failure in edge cases that unit tests may not always exercise.
It would be nice if Kotlin could improve on this state of affairs. I’m sure you must have already considered this topic carefully, as you clearly examined all of the Java puzzlers and tried to fix as many of them as possible. So I’m curious as to whether Kotlin’s current approach (same as Java minus auto-widening) is here for the long term, or whether Kotlin would consider making the default arithmetic operations front to something like Guava’s IntMath/LongMath classes.
The new Swift language from Apple appears to use checked math by default, with special new operators like &+ for unchecked addition, the idea being of course that developers can manually take away the checking if profiling shows it to be a hotspot and the developer is sure the additional safety is unnecessary. I don’t think Kotlin would need new syntax: simply redefining the existing operators and having infix functions for “uncheckedAdd”, “uncheckedDivide” etc would be sufficient.
W.R.T. unsigned types, I guess that can be handled in the standard library by having UByte, UInt, ULong and so on where the standard operators are implemented by something like Guava’s UnsignedInts, UnsignedLongs class. Is that right?