BigInt ceil, floor, round, and trunc?

[js-choi]

I originally did not include BigInt ceil, floor, round, and trunc. However, someone from TC39 (I think it was @ljharb) suggested that we add them as identity functions.

Yesterday, there was some pushback from other TC39 members about this. As far as I can tell, this is bikeshedding and both choices are harmless, but we’ll have to make a decision someday anyway.

CC: @ljharb, @michaelficarra, @waldemarhorwat

[michaelficarra]

I'd rather not add them if they're not motivated by a use case, and I don't think we will find a use case.

[Yaffle]

there is a weird use case:
Imagine you are writing some code that works with both numbers ("safe integers") and bigints:
Math.trunc(a / b)
well.. it can be confusing to the reader...

[michaelficarra]

@Yaffle This assumes we'll be extending the functions on Math to accept BigInts, which is not decided yet. It's possible that we'll be introducing new methods on BigInt, in which case it will always be clear what numeric type you are working with.

[ljharb]

I don't think I was the one to suggest it.

I think it's fine to have them, and I think it's mildly bizarre that the current ones don't support BigInt.

The use case is "i shouldn't have to care if it's a number or a bigint when i'm doing an operation that makes sense for either".

[ljharb]

I'll phrase it differently: I think BigInts and Numbers should always be interchangeable by default, unless that would cause silent precision loss - ie, unless there's a strong reason they should not be.

My preference is that the burden of proof should fall on the argument that both should not be supported, and/or not be mixed - and I agree "precision loss" when applicable is more than sufficient proof.

[jakobkummerow]

@Yaffle Trying to write code that works on both safe-integer Numbers and BigInts is fraught with pitfalls. Consider:
Math.ceil(3 / 2) === 2, but Math.ceil(3n / 2n) === 1n
Not encouraging such code would avoid such footguns.

[Yaffle]

@jakobkummerow , if you are not writing such code, so why do you need Math.ceil(bigint) which is doing nothing?

[jakobkummerow]

@Yaffle : that's my point, I don't see a reason for adding BigInt versions of these functions.

"Adding identity functions doesn't hurt" is not a compelling argument, because by that logic, why stop at four identity functions when we could add hundreds of them? Also, not adding identity functions doesn't hurt either.

"Numbers and BigInts should be interchangeable" is not a compelling argument, because there are many examples where they're clearly not interchangeable and never will be, due to their intentional differences.

[ljharb]

Arrays and strings aren't interchangeable in many ways, and yet, they are interchangeable in many as well. The existence of incompatibilities in no way diminishes the usefulness of maximal compatibility when sensible.