Allow passing in string to NumberFormat.prototype.format()

[mwgamble]

It would be great to be able to pass in a string in the format \d+\.\d* (or something along those lines) and have the number formatter work with it. Right now there's no support for very large numbers, either from BigInt or from a third-party "big number" library like bignumber.js. At the very least, the latter provides functionality to retrieve the full precision number in a non-locale-dependent string form, which should be perfect for passing in to the number formatter.

[sffc]

@littledan added BigInt formatting support in #236. He is also championing a Stage 1 proposal for high-precision decimals. Those proposals should cover most of the bases.

That being said, a smaller feature which could serve this use case would be a scale option that multiplies the number by a power of 10 before formatting. Combined with BitInt, you can then format any arbitrary precision number.

Example:

let num = 987654321n;
let fmt = new Intl.NumberFormat("en-US", { scale: -2 });
fmt.format(num);
// 9,876,543.21

Note that formatting with { style: "percent" } already implicitly performs a scale by a power of ten. This feature proposal would be to make that a public knob.

[mwgamble]

I don't understand why it all needs to be that complicated. Based on my review of a prominent polyfill, the very first thing the code does is cast the number to a string anyway. It therefore follows that it should be easy to just accept strings directly.

[sffc]

There are several problems with accepting strings as part of the spec:

1. We already accept strings (they are cast to Number and lose precision). Treating strings as high-precision decimals would be a breaking change.
2. This would introduce a new syntax surface that we need to support. I'm not aware of anywhere in ECMA-262 or ECMA-402 that currently uses the \-?\d+(\.\d+)(E\-?\d+)? scientific decimal notation. If we start accepting that in Intl.NumberFormat, we will have to put that in front of TC39 and make a conscious decision to start accepting that format as the de-facto decimal string serialization syntax.

Better would be if we had a first-class ECMAScript type for high-precision decimals, which is what @littledan's proposal does, and as a fallback, the BigInt+scale approach gets the job done and is not too bad.

Example of the status quo accepting strings:

const nf = new Intl.NumberFormat();
nf.format("123456789123456789123");  // "123,456,789,123,456,800,000"

[hbgl]

@sffc

About 1.
A new option could be added to treat the argument as a decimal string.

That being said, I like the BigInt+scale approach better.

[sffc]

Closing as a dupe of #334