Because of overflows, and getting rid of them with this idea would be a great option:
Doesn’t need to be.*
That was about changing the default, but the default type for integers doesn’t need to change, only the non-default option, so we do not have to wait for Julia 2.0 (only if we change the default later, what I’m not proposing now).
The question is what should replace the default integers, and I’m a bit conflicted, BigInt or SaferIntegers.jl. The argument for the former is that it’s already built into Julia, and it would give a great incentive to optimize it. I know it’s possible (even already done in some package?). Julia has a policy of not adding stuff Julia itself doesn’t need. That would have been an argument to not have BigInt and rationals in the first place… I would personally be ok with adding SaferIntegers.jl as a stdlib (and even removing BigInt if it’s chosen, moved to a package).
People might say you can already just use e.g. SaferIntegers.jl yourself and change the integer literals in the REPL as an option through a package available. But you have to opt into that from the REPL (or rely on package authors to change to an alternative type). I think we should also have the option for scripts, so that end-users can change the default without changing any code.
* What I have in mind, is that even if the default for literals would change, we could still use machine integers for stuff that matters e.g. array indexing (or even floats seems to work for JavaScript… I know V8 changes to integers behind the scenes). I’m not arguing for making this option fast right away, just available as a non-default option, that people would actually know about if looking at: julia --help
I have my own ideas how to make overflow checks fast, mostly by avoiding them in a lot of cases. Even a compromise of NOT checking for for them for additions only (the most important operation) would go a long way. It hardly ever is the cause of overflowing for 64-bit. That would be multiplying directly or e.g. exponentiation, that can be optimized.
It’s intriguing what can happen with overflows, already warned against (not exploited, yet?) in C (could hypothetically happen in pure Julia code, and even if it/Julia fixed, because if/since issue at lower level in libc/malloc/calloc not fixed, and could also even happen in (otherwise) safe Java) for (most of?) RTOS operating systems and more: Multiple RTOS (Update E) | CISA
EXECUTIVE SUMMARY
- ATTENTION: Exploitable remotely/low attack complexity
- Vendors: Multiple
- Equipment: Multiple
- Vulnerabilities: Integer Overflow or Wraparound
E.g. BadAlloc Vulnerability Affecting BlackBerry QNX RTOS | CISA
On August 17, 2021, BlackBerry publicly disclosed that its QNX Real Time Operating System (RTOS) is affected by a BadAlloc vulnerability—CVE-2021-22156. BadAlloc is a collection of vulnerabilities affecting multiple RTOSs and supporting libraries.[1] A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices.[2]
[…]
CVE-2021-22156 is an integer overflow vulnerability affecting thecalloc()function in the C runtime library of multiple BlackBerry QNX products.
- U.S. Nuclear Regulatory Commission Security Advisory: Blackberry QNX Vulnerability
It may be overblown as nuclear reactors shouldn’t have an internet connection?