| 03:31 | <Richard Gibson> | FWIW, I do not buy this use case. I'm willing to be convinced with concrete worked examples, but conversion isn't even part of Amount right now, and infinite values are just not well-behaved like that (e.g., what would one do with ∞ degrees?) |
| 05:27 | <ljharb> | yeah i don't really buy this either, infinity isn't an amount |
| 05:28 | <ljharb> | the word "amount" is intrinsically finite/discrete |
| 05:28 | <ljharb> | if you want infinity (or NaN) you could use ±Infinity on its own, alongside an Amount |
| 06:02 | <sffc> | Is infinity a valid "measure", but not "amount"? |
| 07:58 | <Richard Gibson> | please don't take things in that direction. We don't need synonyms, we need concrete worked examples. And like I said, I am willing to be convinced... it's certainly possible to have an infinite estimated duration due to total lack of progress for e.g. file transfers at 0 bytes/s or speed of 0 m/s, so it's not like the concept is impossible or incomprehensible. But it does also cause problems like lack of valid decimal (and hence JSON number) representation, and we should try to avoid inclusion doing more harm than good—especially since support could be added later, but can never be removed. |
| 11:46 | <eemeli> | Amount's internal-slot access from Intl.NF was raised as a concern by at least KG and MM. If we want to avoid that, I think we may need to add a Another alternative would be to have Intl.NF be able to parse the serialized form Are there other choices here? The proposal's spec text currently looks for the [[Value]] and [[FractionDigits]] internal slots. |
| 12:50 | <Jesse> | I'm glad MM and KG brought up the internal slot issue. I like the idea that Intl.NF do lightweight parsing (grabbing the substring of toString() up to the first [, if any). Having .valueof() return a string also strikes me as intuitively appropriate though I wonder if we might be painting ourselves into a corner somehow |
| 12:52 | <Jesse> | Shane posted an interesting example: https://github.com/tc39/proposal-measure/issues/50#issuecomment-3134873158 |
| 12:56 | <Jesse> | so far I think the example uses of infinite amounts arise not from direct use of infinity, but inferred/calculated infinity like division by zero. This makes me wonder whether we should support infinity out-of-the-box, now, or defer the discussion to proposal-smart-units, which is concerned with the kinds of examples we've seen so far |
| 13:02 | <Jesse> | regarding Ashley's request for BigInt(new Amount(bigint)), I guess that would be solved by having Amount's valueOf return a string (without unit)? |
| 13:06 | <Jesse> | (hmm, maybe not, nvm) |
| 13:07 | <Jesse> | how feasible would it be to add a new bigint hint to ToPrimitive? |
| 13:08 | <nicolo-ribaudo> | What if we just didn't add toPrimitive on amount |
| 13:09 | <nicolo-ribaudo> | And made valueOf return the string |
| 13:10 | <nicolo-ribaudo> | It means that amount+amount would do string concatenation, but that seems fine |
| 13:10 | <nicolo-ribaudo> | You should extract the numbers before doing math anyway |
| 13:20 | <Jesse> | I might be misremembering but my understanding of the discussion that brought us to the infinity topic was the possibility that Amount might generate an infinite value when converting to Number or BigInt (or, looking into the future, Decimal). There's a kind of mismatch between the vision we offer of (more or less) unlimited finite values and the hard reality that Number (and Decimal) are limited. One way to resolve this would be to have Amount's toNumber() throw if it would produce ±Infintiy |
| 13:21 | <Jesse> | iow I wonder if the discussion was initially triggered not so much by whether we accept infinity, but whether we emit infinity |
| 13:24 | <Jesse> | there could be an option in toNumber() to actually produce ±Infinity, but throw by default |
| 15:58 | <eemeli> | My understanding is that infinity was raised as a concern by WH as it's a value that's supported by Number. And that he would also want to see NaN being supported. |
| 15:59 | <eemeli> | So their support comes from wanting to have Amount work as an "annotated Number". |
| 16:45 | <sffc> | Before jumping in head-first on this, we should discuss it with TG3. They didn't seem to realize that Intl.DateTimeFormat does the internal slot thing too. If we did do this, I think it should be a getter for |
| 16:50 | <Jesse> | I could invite MM to the next TG3 call and we could book a bit of time to walk through the internal slots issue |
| 17:01 | <ljharb> | it's neither, it's a concept, not an actual number. |
| 18:30 | <Jesse> | do we still want to discuss the infinity issue in a continuation? or would we prefer to iterate on that here and GH? |
| 18:38 | <Jesse> | done |
| 18:38 | <Jesse> | we should make an issue for this and add it to the agenda |
| 20:29 | <nicolo-ribaudo> | nice |
| 20:36 | <Jesse> | Mark says he'll attend the August 14th TG2 call |
| 20:36 | <Jesse> | to talk about internal slots and Intl |
| 20:38 | <Jesse> | (talking about this in TG3 would also make sense of course) |
| 20:38 | <sffc> | For Infinity, I think we need to get champion group alignment first |
| 20:38 | <eemeli> | The Amount repo has been renamed: https://github.com/tc39/proposal-amount |
| 20:39 | <sffc> | But I'm going to suggest that we could take some time to discuss the Intl MV limits issue |
| 20:39 | <Jesse> | sgtm |
| 20:39 | <Jesse> | I've poked CDA to add a continuation |
| 20:40 | <sffc> | It's less a continuation and more of a new topic, but sure |
| 20:43 | <Jesse> | would you like to screenshare that issue? |
| 20:43 | <sffc> | Yeah |