Adapting `ToIntlMathematicalValue` to not read internal slots

[jessealama]

As it stands, the Amount proposal reads internal slots in calls to ToIntlMathematicalValue, which happens when we use Intl.NumberFormat to format an Amount. We thus end up consulting internal slots of an argument of a function, which is problematic for membrance transparency.

How shall we do this? I see two paths forward:

1. Ensure that ToIntlMathematicalValue ends up working with a String version of the underlying Amount
2. Checking for .fractionDigits and .unit properties (not internal slots)

(1) would work by changing step 1 ofToIntlMathematicalValue so that the call to ToNumber receive a ~string~ hint rather than a ~number~ hint. This aligns nicely with the work going on in proposal-intl-keep-trailing-zeros.

Option 2 also seems fine. It feels like it aligns well with how Intl.NF(.p.format) works.

[jessealama]

cc @kriskowal

[nicolo-ribaudo]

My preference would be option 1, if that's possible. As far as I understand it does not change the behavior for bigints and numbers with their builtin @@toPrimitve method.

Engines can optimize the case where @@toPrimitive is unmodified to not actually allocate the string when it comes to numbers/bigints/amounts.

[eemeli]

As I understand it, Option 1 would require Intl.NumberFormat to be able to parse input strings like

• '1.0[kilogram]' or
• '42[EUR]'

while Option 2 would require supporting objects like

• { valueOf: () => 1, fractionDigits: 1, unit: 'kilogram' }
• { toString: () => '42', unit: 'EUR' }

Of these, I would prefer Option 1, as it avoids the following compatibility issues:

1. The conceptual meaning of "fraction digits" or other measures of precision, which for Amount are always referring to the mathematical value, whereas Intl.NumberFormat associates these with the formatted results:

   new Intl.NumberFormat('en', { minimumFractionDigits: 2 }).format(0.12)
   // "0.12"
   
   new Intl.NumberFormat('en', { style: 'percent', minimumFractionDigits: 2 }).format(0.12)
   // "12.00%"
   
   new Intl.NumberFormat('en', { notation: 'scientific', minimumFractionDigits: 2 }).format(0.12)
   // "1.20E-1" 

2. The mismatch caused by Amount using unit also for currencies, while Intl.NumberFormat uses currency as the constructor option setting the currency.
3. The way we would still need to retain effectively the current ToIntlMathematicalValue implementation in order to parse the value of the object's wrapped value, when it is a digit string.

[kriskowal]

I find the string representation attractive because it only requires one datum to pass from the amount to the formatter and eliminates the number of observable hand-offs. Is the intention that Intl.NumberFormat would accept string and not Amount objects, or that it would coerce Amount to string as a protocol?

[nicolo-ribaudo]

That it would coerce to string (it currently coerces already, but to number).

[nicolo-ribaudo]

A third idea: instead of the string, we check if it has a @@symbolFormattable: true, and then only do the duck-typing of option 2 in that case.

[waldemarhorwat]

Slot values are validated on entry. Option 2 has the problem that it lets through impossible combinations of slot values.