Intl.NumberFormat support

[littledan]

It seems like Intl.NumberFormat.prototype.format should support BigDecimal transparently, just as it supports BigInt.

On the ICU level, this should be straightforward, using the same API as BigInt uses.

On a function API level, we have clear precedent with BigInt that we should overload the format and formatToParts methods.

The complexity comes in for options processing: NumberFormat is based on rounding the input, but BigDecimal is all about avoiding implicit rounding. How should that all be handled?

[littledan]

cc @sffc

[littledan]

The complexity comes in for options processing: NumberFormat is based on rounding the input, but BigDecimal is all about avoiding implicit rounding. How should that all be handled?

Maybe this mismatch goes away if BigDecimals are always normalized? The main difference would be in how the default is treated: BigDecimals should omit rounding by default, I think, not round on Number's terms. If rounding options are used explicitly, then great, no mismatch.

[sffc]

I think it would be reasonable if BigDecimal had a different default rounding strategy than Number (or BigInteger), but it should still allow Intl.NumberFormat to apply its own rounding. For example, when rendering a currency, you should obey the currency rounding rules.

[nicolo-ribaudo]

Given some discussions from the past few months, I'm thinking that maybe we should make Intl.NumberFormat.prototype.format throw when it receives a decimal, at least if the constructor didn't explicitly receive some options about the precision of the number.

I have been convinced that, for localization/display purposes, the precision is important and should be explicit somehow, either as new Intl.NumberFormat({ minSignificantDigits: 2, minSignificantDigits: 4 }).format(decimal) or as new Intl.NumberFormat().format(decimal.toAmount({ significantDigits: 2 })).

[sffc]

I agree with @nicolo-ribaudo, in the sense that a "point on a number line" is a machine concept and not intrinsically a localizable value. It is localizable after the scale of the value is specified.

I could still be convinced that we should treat normalized decimals the same as (normalized) floats to make things like migrating code bases easier. But this seems like something easy to add later when we have more evidence.