Large and small values

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.

No source files or tests are named in the payload. Start with issue #52 as an API design discussion, examining overflow behavior, notation thresholds, engineering notation, and precision; the work is done when these choices are specified clearly enough to implement and test.