TC39 Decimal_Measure on 2025-04-11

00:04	<sffc>	* What do people think of this comparison: in Temporal, by themselves, MonthDay or YearMonth might not be super strongly motivated. We would have been able to achieve most of the value proposition of Temporal by just having PlainDate. However, the champions decided amongst themselves that these two types were an important part of the whole overall package of an ergonomic datetime API. The plenary trusted our judgement, and now we have the types. In a similar way, Decimal.Amount should be a type that we position as motivated as a piece of the ergonomic numerics type system, and it is just one piece of the proposal that we put in front of plenary. I don't think it is right to position this as a question we ask plenary: "should we include Decimal.Amount?" That's just an opportunity for inconclusive debate around what it means to be motivated and what is the bar for being motivated and what the alternatives could be. In Temporal, we didn't ask "should we include Temporal.PlainYearMonth?" We just included it as part of our package. Delegates who were interested left feedback on GitHub. This is what we can and should do with Decimal.Amount.
00:05	<sffc>	* What do people think of this comparison: in Temporal, by themselves, MonthDay or YearMonth might not be super strongly motivated. We would have been able to achieve most of the value proposition of Temporal by just having PlainDate. However, the champions decided amongst themselves that these two types were an important part of the whole overall package of an ergonomic datetime API. The plenary trusted our judgement, and now we have the types. In a similar way, Decimal.Amount should be a type that we position as motivated as a piece of the ergonomic numerics type system, and it is just one piece of the proposal that we put in front of plenary. I don't think it is right to position this as a question we ask plenary: "should we include Decimal.Amount?" That's just an opportunity for inconclusive debate around what it means to be motivated and what is the bar for being motivated and what the alternatives could be. In Temporal, I don't recall us asking "should we include Temporal.YearMonth?" We just included it as part of our package. Delegates who were interested left feedback on GitHub. This is what we can and should do with Decimal.Amount.
08:09	<eemeli>	Decimal but no ergonomic solution for its i18n interop sffc What would this look like? As we've agreed that Decimal (the one that does math) won't include precision, my understanding is that without any changes in ECMA-402 attempting to format a Decimal with NumberFormat or select its plural category will call its `.toString()` method, and get the user the result that they might expect from the Decimal's numerical value. This won't really add any new capabilities for number formatting, but it won't take them away either, so I don't see how the i18n interop of even a minimal Decimal would not have an ergonomic solution.
08:11	<eemeli>	Also, just to clarify, I am not advocating for a polymorphic Amount, and I'm not aware of anyone else doing so either. I do think that a black-box Amount would be sufficient for i18n purposes, but that's not the same thing.
08:15	<nicolo-ribaudo>	The "good intl support for decimal" that Shane would be happy with is something along the lines of https://github.com/nicolo-ribaudo/proposal-numeric-with-precision (but just for decimal, and without the protocol). It's what evolved in the discussions of merging decimal and measure, but we can figure out what's the _minimal_ chunk that would need to be added to Decimal that: - is good enough for intl - can be extended by the measure/amount proposal
13:05	<Jesse>	can you say more about what a black-box Amount is, versus a minimal Amount?
13:06	<Jesse>	atm the current Decimal.Amount does almost nothing, except string formatting and equality comparison (which itself is pretty trivial)
13:06	<eemeli>	It's an Amount that doesn't directly tell you what its contained value is, so it's only available as e.g. a string.
13:07	<Jesse>	ah, I see. At the moment that's what we've got, though the current design needs to be updated somewhat if we want this to be a basis for measure, and not just the end of the road for Decimal
13:22	<Jesse>	another alternative is that Measure/Amount is its own primordial
13:23	<Jesse>	we've talked about the 2-class vs. 3-class approach before, and argued in favor of the 2-class approach, but I wonder if we want to revisit that
13:24	<Jesse>	the line of thinking I have in mind is: is Measure really so close to Decimal.Amount that Measure has to be viewed as an extension of Decimal.Amount?
13:25	<Jesse>	if we look at Decimal.Amount as a solution to a couple of problems arising from the decimal problem space, then maybe it's just an accident that Measure -- if you drop some data -- looks like a Decimal.Amount
14:39	<littledan>	OK, I guess I'm sold on Decimal.Amount at this point
14:39	<littledan>	we should probably go back and make sure it has the full IEEE data model though (including negative precision)
14:40	<littledan>	it vaguely makes sense to model significant digits (?)
14:40	<littledan>	I guess I see little risk of 1., but cannot disagree with you that 2. is a possibility
14:41	<littledan>	yes, Temporal is a strong reference point for "let's not worry too much about making too many classes, and make sure we have a clean division of what's logically actually represented, rather than filling in nulls"
14:41	<littledan>	except the difference is that Decimal.Amount is much lighter-weight
14:42	<littledan>	(what if we called the class Decimal.WithPrecision?)
14:54	<nicolo-ribaudo>	What if for now we call it `Decimal.ThatObject`, and just name it further ahead during stage 2 once both the proposal are at stage 2? :)
14:54	<littledan>	heh Amount is fine for now
14:54	<littledan>	anyway I've flipped the polarity of how I feel about this proposal
14:54	<littledan>	not sure what I was thinking...
14:55	<littledan>	it's nice and minimal
14:57	<nicolo-ribaudo>	(disclosure :P) I was talking with Dan about this potential minimal version of this: https://nicolo-ribaudo.github.io/proposal-decimal-with-precision/ and https://github.com/nicolo-ribaudo/proposal-decimal-with-precision It's currently broken because I forgot to round, and it has the .with method naming that Eemeli suggested to change, but it could be a good starting point
15:04	<eemeli>	Is this not satisfied by indicating significant digits with a positive integer number?
15:06	<littledan>	well, yeah, that's what IEEE calls it, but this proposal flips the sign bit, but that's fine
15:06	<littledan>	I think it's probably more intuitive for positive to mean "more decimal places"
15:15	<eemeli>	I would prefer `Decimal.ThatObject`, or some other clearly not-final name for the part that is getting packaged into the decimal proposal. The i18n problem/need that it's fulfilling was only accepted by committee as a part of the measure proposal, and the clear intent is for it to be filled out with `unit` and `currency` fields by the measure proposal.
15:17	<littledan>	sure, SGTM
15:26	<eemeli>	Jesse: Regarding this phrase in the slides: We propose a new Decimal.Amount primordial for storing a (1) decimal value (2) with a precision (3) but without a unit. Would it be perhaps more appropriate to phrase it a bit like this? We propose a new Decimal.Amount primordial for storing a decimal value with a precision. If accepted, the measure proposal may add fields to this primoridal to store unit or currency indicators.
18:27	<Jesse>	Yes, that’s closer to the intention — I’ll change it, thanks!
18:59	<Jesse>	would we need something like a `.withQuantum` method (name TBD) to expose this kind of capability? It could take a positive or negative integer (negative would be equivalent to `.withFractionalDigitss` with a negated argument)
19:02	<nicolo-ribaudo>	We should pick just one probably, especially because the word "quantum" is not very well known
20:10	<littledan>	yes, "precision" is way more clear than "quantum"
20:30	<nicolo-ribaudo>	For precision, I think both toFixed and Intl use positive numbers to mean "more digits of precision", so it'd be great to follow that. I don't actually know what the current PR does, or what IEEE does.
20:30	<nicolo-ribaudo>	I think we should stay within what can be encoded by IEEE, but we can expose it differently. Is the quantum the number of fractional digits or of significant digits?