Why reuse Math namespace?
elijahrdorman opened this issue · comments
The creation of the Math namespace never made much sense in the first place. It also seems unnecessarily confusing that some methods work while others do not.
Instead, why not attach them directly to BigInt where they belong?
In the case of abs (for example), I'd recommend going with BigInt.abs for traditional static use like BigInt.abs(-123) and BigInt.prototype.abs for use as either foo.abs() or a literal (-123n).abs()
Because if they’re on BigInt they can’t take both Number and BigInt (and one day, perhaps, Decimal).
@ljharb If I do 5n + 5 I'll get the following Error
Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions
Is there any reason why explicit conversion would be required for operators, but not for these math operations?
If the operation could result in precision loss, then the decision is that it throws (ie, requires explicit coercion).
However, many Math operations do not result in precision loss, and there is thus no reason to harm usability by requiring that coercion.
Are there any proposed cases that match this criteria aside from min and max?
What potential additions would match that criteria, but have not been proposed?
Looking at the readme, abs, sign, clz32, min, and max.
There's no reason ceil/floor/round/trunc couldn't also accept bigints, but also no real reason to allow them to.
abs, clz32, and sign are all unary, so the question of mixing numeric types is irrelevant.
popcount, bitLength, gcd, clz64, and modInv are all basically pointless for Number.
modPow is not only pointless for Number, but because it's almost exclusively limited to crypto, seems like a bad idea for BigInt because it isn't O(1).
This still leaves the only overlapping, non-unary mixed functions as min and max. In all other cases, it seems like there's just room for confusion about which various Math functions work with whatever number type (something that gets even worse with decimals in the mix).
