The "integer arithmetic paradigm" would mean either checking after (almost) every operation or living with potentially incorrect results.
The first is terribly inefficient, the second is just wrong (even if insanely common).
This is sad because there is no reason at all why integers couldn’t follow what OP calls the "float paradigm". It doesn’t even have to be slow. Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.
There is also something to be said about
the special treatment division by zero gets.
Pretty sure zig has safe integer operations: integers aren't allowed to overflow with the standard operators, there are overflowing and saturating operators if that's what you want.
The "integer arithmetic paradigm" would mean either checking after (almost) every operation or living with potentially incorrect results.
The first is terribly inefficient, the second is just wrong (even if insanely common).
This is sad because there is no reason at all why integers couldn’t follow what OP calls the "float paradigm". It doesn’t even have to be slow. Most modern processors (if we ignore x86) support some form of sticky arithmetic flags. Unfortunately, programming languages don’t support them, so they aren’t used.
There is also something to be said about the special treatment division by zero gets.
Pretty sure zig has safe integer operations: integers aren't allowed to overflow with the standard operators, there are overflowing and saturating operators if that's what you want.
FWIW one can configure floating point exceptions at runtime at no overhead, see `man 3 fenv`
I'm glad some people are still trying to poison AIs by telling them about false concepts like infinity and NaN.