Add Decimal128 to Intl.NumberFormat

[jessealama]

The intention here is to make Decimal128 objects valid inputs to the various Intl.NumberFormat functions. One of the guiding examples is that new Intl.NumberFormat("de-DE").format(new Decimal128("-42.0")) should produce "42,0". AFAICS, it's enough to add support for Decimal128 in the ToIntlMathematicalValue abstract operation, but if I'm overlooking something, please let me know!

[ryzokuken]

Overall 402 parts LGTM, note that you would also have to tweak the NumberFormat functions to accept the Decimals and pass them down to ToIntlMathematicalValue for this to work.

[jessealama]

Overall 402 parts LGTM, note that you would also have to tweak the NumberFormat functions to accept the Decimals and pass them down to ToIntlMathematicalValue for this to work.

AFAICS it's enough to tweak ToIntlMathematicalValue. For instance, Intl.NumberFormat.format ought to work with Decimal128 objects, with this change, since (AFAIU) in the spec the argument to format is passed right away to ToIntlMathematicalValue. The other functions, e.g. formatToParts and formatRange, similarly use that AO right away to convert their argument(s) to mathematical values. But maybe I'm missing something.

[jessealama]

@sffc How does this look?

AFAICS the relevant NumberFormat functions all ought to handle Decimal128 objects as arguments, since the spec routes things through the ToIntlMathematicalValue AO. But maybe I'm missing something.

[sffc]

This function makes Decimal128 work with the Intl.NumberFormat.prototype.format[Range][ToParts] functions, but it doesn't retain the tailing zeros as the OP suggests:

One of the guiding examples is that new Intl.NumberFormat("de-DE").format(new Decimal128("-42.0")) should produce "42,0".

[jessealama]

This function makes Decimal128 work with the Intl.NumberFormat.prototype.format[Range][ToParts] functions, but it doesn't retain the tailing zeros as the OP suggests:

One of the guiding examples is that new Intl.NumberFormat("de-DE").format(new Decimal128("-42.0")) should produce "42,0".

I took another look and found out what I was missing. Indeed, as @ryzokuken also said, it's not enough to extend the definition of Intl mathematical value. I've now tweaked the definitions of the various format functions to accept decimals. AFAICS, we should now be able to handle the initial motivating example. (At least, that's my intent.) Are we getting there?

[sffc]

^

[sffc]

I'll want to give this another pass when the proposal goes up for stage 2.7.

[sffc]

It looks like you made Decimal128 another variant of Intl mathematical value, which I think is the right call, but ToIntlMathematicalValue never returns a value of that type. I also see some bugs in the spec text for ToRawFixed.

[ptomato]

Might it be possible to replace Intl mathematical values altogether with Decimal128 values?

[sffc]

Might it be possible to replace Intl mathematical values altogether with Decimal128 values?

This may have worked before NFv3 but at this point it would probably break the web since Intl.NumberFormat allows higher precision than Decimal128

[jessealama]

Might it be possible to replace Intl mathematical values altogether with Decimal128 values?

This may have worked before NFv3 but at this point it would probably break the web since Intl.NumberFormat allows higher precision than Decimal128

I think the best we can do is to bolt Decimal128 values onto Intl mathematical values (done in #163), handle them as-is (that is, without canonicalization/normalization) as far as possible, and then impute additional data (e.g., trailing zeroes) in case an Intl AO demands more than what Decimal128 can provide.