Using BigInts with Amount should not be painful

[eemeli]

With the changes in #86 and #104, we've introduced a regression for BigInt Amounts. Specifically, we've made it so that seemingly innocent code like this will fail:

let a = new Amount(42n, { unit: 'kilometer' });
let b = a.convertTo({ unit: 'meter', fractionDigits: 0 });
BigInt(b.value); // Uncaught SyntaxError: Cannot convert 4.2000e+4 to a BigInt

or even more simply:

let a = new Amount(42n, { fractionDigits: 0 });
BigInt(a.value); // Uncaught SyntaxError: Cannot convert 4.2e+1 to a BigInt

The problem here is that while Number('4.2000e+4') succeeds, BigInt() can't handle string inputs in exponential notation, even if they're representing an integer value.

I think it would be nice if the code presented above would not fail.

My (at least initially) preferred solution here would be to use SignedInteger notation to represent integer values for which the precision matches the integer digit count, i.e. using '42' instead of '4.2e+1'.

This won't of course guarantee that all values are convertible to bigints, but it would at least help ensure that with { fractionDigits: 0 } they are.

[gibson042]

The problem here is that while Number('4.2000e+4') succeeds, BigInt() can't handle string inputs in exponential notation, even if they're representing an integer value.

I think it would be nice if the code presented above would not fail.

My (at least initially) preferred solution here would be to use SignedInteger notation to represent integer values for which the precision matches the integer digit count, i.e. using '42' instead of '4.2e+1'.

This won't of course guarantee that all values are convertible to bigints, but it would at least help ensure that with { fractionDigits: 0 } they are.

I agree that this is a problem, but rather than fork the canonical representation of an Amount's value, I'd prefer to extend BigInt for supporting exponential notation such that BigInt("4.2e1") === 42n. It's already true that BigInt(4.20e1) and BigInt(42.0) succeed because BigInt accepts the strict subset of number-typed inputs that are integers, and would make sense IMO for treating strings similarly. WDYT?

[sffc]

Seems like a bug in BigInt. Also, it can be fixed in parallel with Amount since it is a code driven rather than data driven exception.

[gibson042]

it is a code driven rather than data driven exception.

@sffc I don't understand what this means; can you explain?

[sffc]

it is a code driven rather than data driven exception.

@sffc I don't understand what this means; can you explain?

The code will always fail no matter what value of BigInt is provided. This is unlike previous iterations that used non-scientific formatting when possible and scientific only when required, which would have caused a data-driven exception.

[jakobkummerow]

Counter-point: using BigInts with Amount makes no sense in general, so it doesn't matter if it's painful.

Converting km to m is a trivial example where one might argue "why can't it just work", but it's also not the most interesting use case. Converting km to miles (or inches to cm, or kg to lbs, or °C to °F, etc) is a lot more interesting, and clearly unsuitable for BigInts. Heck, even the inverse of the motivating example (converting meters to kilometers) is clearly unsuitable for BigInts: how many km is 500n meters? (And: who counts distances in integers anyway?)

So, counter-suggestion: just drop BigInt support for anything that supports unit conversion. If Amount is just "a value with a unit", supporting BigInts might not hurt; if Amount is "a value with a unit that supports conversions", then trying to contort BigInts into it is asking for trouble (in particular: various forms of inconsistent behavior, and overly complex implementations that are required for spec-compliant edge cases but irrelevant because useless in practice).