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:
- Ensure that
ToIntlMathematicalValue ends up working with a String version of the underlying Amount
- 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.
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:
ToIntlMathematicalValueends up working with a String version of the underlying Amount.fractionDigitsand.unitproperties (not internal slots)(1) would work by changing step 1 of
ToIntlMathematicalValueso that the call toToNumberreceive 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.