| 08:06 | <Jesse (🇪🇸)> | agreed, though I think in our case we ought to have that guarantee because we track precision |
| 08:14 | <eemeli> | That works fine for number+precision, but what happens when we include units and currencies in the Amount? <42, EUR> and <42, USD> should not compare as equal, but if their toString() values are different to ensure that, how can a user easily get at the '42' string value? For a toy example like this that can be available via e.g. .toDecimal().toString(), but that breaks for values beyond 34 digits. |
| 08:15 | <ljharb> | the latter part seems expected tho |
| 08:15 | <eemeli> | Which "latter part"? |
| 08:15 | <ljharb> | if you can't make a numeric and then get the string you want, then it seems like you just can't get that string? |
| 08:15 | <ljharb> | phrased another way, if decimal can't stringify properly after 34 digits that's a problem to fix in decimal, not amount |
| 08:16 | <eemeli> | For context, I'm thinking here of a non-Decimal Amount, i.e. one that can support numerical string values beyond Decimal. |
| 08:17 | <ljharb> | ah |
| 08:17 | <eemeli> | As in, values in the numeric string range supported by Intl.NumberFormat. |
| 08:17 | <eemeli> | (Anything up to Number.MAX_VALUE, with up to 100 fraction digits) |
| 08:18 | <ljharb> | ah |
| 08:19 | <sffc> | .toString can have an options bag similar to Temporal .toString functions |
| 08:20 | <sffc> | .withUnit(null).toString() would work, too. But not .toDecimal().toString() as it loses precision. |
| 08:21 | <eemeli> | I had not noticed the Temporal toString options bags, that would certainly work for me. |
| 08:23 | <Jesse (🇪🇸)> | do we want to expose any limits coming from Decimal128 à la Math.MAX_VALUE? |
| 08:27 | <eemeli> | I think not, because that would unnecessarily limit support of all bigint values. |
| 08:28 | <eemeli> | (corrected my comment above to refer to Number.MAX_VALUE, which is what I meant) |
| 08:30 | <Jesse (🇪🇸)> | maybe this is a question for the decimal proposal in the narrow sense, not related to amount/measure |
| 08:51 | <Jesse (🇪🇸)> | one of the tasks for the minisummit is to iterate on the README |
| 08:51 | <Jesse (🇪🇸)> | I've made some changes and will push them to GitHub |
| 08:51 | <Jesse (🇪🇸)> | we can work there |
| 08:53 | <Jesse (🇪🇸)> | https://github.com/tc39/proposal-decimal/pull/195 |
| 10:36 | <Jesse (🇪🇸)> | thanks everyone for chipping in |
| 10:37 | <Jesse (🇪🇸)> | I'm glad that we dug in to the string-backed amount idea |
| 10:38 | <Jesse (🇪🇸)> | I think there's still some uncertainty about that |
| 10:38 | <sffc> | My research question going into that was "are there delegates hesitant about String-based Amount who are onboard with Decimal-based Amount" and I think the answer to that is, yes |
| 10:39 | <Jesse (🇪🇸)> | right |