That might actually work out quite well. I guess a secondary benefit would be to get rid of many type-specific overloads in all those number types which clutter the API docs
A related change which is already been discussed is making the default number type depend on the architecture (i.e. Int64 on 64-bit systems), which would just give a lot more value range for most math operations by default. Without that, it would be tedious if you want to calculate using the wider value range of Int64 but all the numbers returned from method calls are Int32 and need to be explicitly casted.
On the downside, these effects would not spill down to 32-bit and it would result in a huge split because the same math operations that work perfectly well on 64-bit architectures might simply fail on 32-bit because of overflow.
Aside: I find this a very cool project, if only for the reason that about 15 years ago I helped a CompSci grad student here at RPI with some work they were doing on twinprimes.
Or you could create by default that 32-bit systems use 64-bit math underneath, i.e. use 32-bit doubles. Once you do that, all your operators will work without the programmer having to explicitly cast values. If a programmer wants/needs to do real 32-bit operations (shifts, rotates, et al), its easier to convert down than up.
It’s the same issues you have now if you want to do 128-bit math on 64-bit systems, you have to use 64-bit doubles.
This is what Ruby does automatically underneath, converting to BigInt, Float, etc, where necessary to give expected results.
