| 04:33 | <eemeli> | Correct; we would effectively end up with a "three-class" solution where one of the "classes" is a numeric string, i.e. the solution for representing units or currency codes would be wholly separate. |
| 11:57 | <littledan> | eemeli: Why would this be better? |
| 12:39 | <eemeli> | littledan: Because we already support numeric strings for Number(), Intl.NumberFormat & Intl.PluralRules input, and we provide utilities like Number.p.toPrecision to generate them. It is an existing representation of a numerical value with a precision that's supported in JavaScript. I would much rather we make better use of a thing that already exists than inventing a new thing that's functionally almost exactly the same. |
| 12:47 | <littledan> | it feels like we're going in circles; we've already discussed why the weak typing of strings makes them not a reliable option |
| 13:19 | <eemeli> | Is this unreliability something that has an impact on the formatting use cases of a number-with-precision? |
| 15:28 | <Jesse> | AFAICS even if we were to patch Intl.NF.p.format to handle arbitrary digit strings, and even if that fix were web compatible, it wouldn't address the footgun when mixing NumberFormat and PluralRules |
| 15:32 | <sffc> | We would want to fix both Intl.NF.p.format and Intl.PluralRules.p.select to respect the significant digits of strings. (I think this may be a good change to make anyway, independent of the Decimal proposal) |
| 15:45 | <littledan> | yeah, the fact that we were able to make the string change in the first place (it used to cast to Number!) makes me optimistic that this will be web-compatible |