A better rule of thumb is to always use signed integers, except for bit twiddling and modulo-math.
Especially with 64-bit integers it's really no longer an issue to lose one bit for the sign (63 bits ought to be enough for anybody heh).
A better rule of thumb is to always use signed integers, except for bit twiddling and modulo-math.
Especially with 64-bit integers it's really no longer an issue to lose one bit for the sign (63 bits ought to be enough for anybody heh).
If you can open your mind to dependent types, then Fin is even better, which also avoids overflow by construction. But then again dependent types are a whole different beast when it comes to compilers and language capabilities and so on.
[0] https://www.boost.org/doc/libs/develop/libs/safe_numerics/do...
[1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...
Beyond that, the decision whether a number is signed or unsigned is only needed for string formatting (e.g. it's like Schroedingers integers: whether a number is signed or unsigned only matters when you actually look at the number).
But in any case: with 'sign-agnostic' integer types high level languages would simply need separate signed vs unsigned mul/div operators. Not a big thing when modern languages already have different operators for wraparound vs overflow-checked arithmetic (for instance + vs +% in Zig).