Large and small values

[waldemarhorwat]

What should Amount do when presented with very large or very small values such as 1.234e1446 or 3.48e-123? The choices I see are:

1. Throw
2. Output very long strings
3. Output in exponential notation

1 is bad for the same reason that throwing on infinities and NaN is bad. The values fed to Amount are often sourced from user data, and it adds a landmine where users can provide simple and valid input that crashes the application.

2 works and is perhaps the simplest approach. Here we'd run into an issue of what happens when the user feeds in "1.23e1000000000000". There is existing precedent for such cases that arises when trying to create a very long string or BigInt: practical implementations have some limits on the length of a string or BigInt.

3 is the safest approach and results in reasonable behavior for all inputs. If we have exponential notation, this brings up a couple questions: precision and threshold.

Exponential notation threshold

The default threshold for switching to exponential notation should be quite large — I'd suggest rendering values with exponents in the range -99 to 99 in regular notation and exponents outside of that range in exponential notation.

• Should we let users customize the threshold or perhaps force the output as exponential notation? This might be useful in some cases.
• Should we support engineering notation, where the exponent is always a multiple of 3 and the mantissa magnitude ranges from 1 inclusive to 1000 exclusive for nonzero values?

Exponential notation precision

The next question is whether we should retain the precision of "1.23400e123" vs. "1.234e123" so the first one retains its trailing zeroes when output? The current proposal does retain it in significantDigits but handles fractionDigits incorrectly. If we expose fractionDigits, for such values fractionDigits must be negative.

[ljharb]

Both 2 or 3 seem fine to me.

_{That said, I don't think that 1 is actually bad - it won't crash the application unless the developer has failed to try/catch, or validate the input, just like any other place in the language that throws an exception. It's simply not a dealbreaker in an application for some kinds of data within the same type to cause exceptions - much of the language has this behavior in various ways.}

Re threshold, both a large default and making it customizable makes perfect sense to me. I'm not as convinced by "engineering notation" but that seems like an easy follow-on later if it's well-motivated.

Re precision, I think yes, we should preserve it.

[eemeli]

This is specifically about the Amount.p.toString() output, yes? My initial sense here would be that we ought to have the same behaviour as Number.p.toPrecision() (except for the step 5 RangeError), as that would retain an accurate representation of the value's precision.

[jessealama]

relates to #47