TC39 Decimal_Measure on 2024-12-18

00:33	<ljharb>	I think in Temporal we ended up with the right data model, and we worked out a way to make it not be too "noisy" that’s because everything is only objects there - numbers ideally would eventually be primitives, and we should be designing with that goal in mind.
01:12	<littledan>	that’s because everything is only objects there - numbers ideally would eventually be primitives, and we should be designing with that goal in mind. Is there anything in the design that we described that wouldn’t work well with that?
01:12	<littledan>	If only the decimal is primitive, and measure is always object
01:12	<ljharb>	no that would work fine
01:13	<littledan>	If only the decimal is primitive, and measure is always object This being the future state, and the initial proposal focusing on the wrappers
01:13	<ljharb>	(because most people wouldn’t likely use measure except to handle formatting with intl)
01:14	<littledan>	(because most people wouldn’t likely use measure except to handle formatting with intl) Arguably people should be doing unit-ed computations all over the place, but I think that is beyond the scope of measure (initially)
01:14	<littledan>	Also that isn’t really demonstrated in any other mainstream programming language
01:15	<littledan>	Our destiny in TC39 is to be followers, not leaders
01:16	<littledan>	This being the future state, and the initial proposal focusing on the wrappers Ljharb: just wanted to check, does this caveat weaken things?
01:16	<littledan>	(Within the context of, decimals are canonicalized)
01:17	<ljharb>	which, the primitives later? I’m def still unconvinced advancing anything without primitives is worth it, but it at least removes my objection on the basis of blocking primitives
01:18	<littledan>	Seems like we are at a point of common understanding, which is good
01:18	<littledan>	Even if we differ on tradeoffs
01:36	<littledan>	Eemeli: do you have remaining concerns about introducing classes as opposed to just using strings or something?
08:08	<eemeli>	I don't see how "just using strings" is a viable option for communicating precision, because we already assign meaning to formatting string values: `new Intl.NumberFormat('en').format('1.8000') === '1.8' new Intl.NumberFormat('en').format({ toString: () => '1.9000' }) === '1.9'` Or did you mean something else? I do not have any qualms about introducing a Measure class. If we do, I think it could well serve many of the use cases presented for Decimal as well.
08:09	<eemeli>	Because Measure doesn't exist, we could (should?) of course define its handling of string values to retain precision, so we'd end up with: `new Intl.NumberFormat('en').format(new Measure('1.8000')) === '1.8000'`
08:11	<Jesse>	that looks good -- that matches what I had in mind for measure & NF
08:12	<Jesse>	also, measure should work with any additional specifiers, such as num-significant-digits or num-fractional-digits, as it works today with strings
12:13	<littledan>	Re strings: oops! That was kind of an unforced error; we added that support somewhat recently, though I guess before we had thought much about how exactly decimal should work. Remember, that was already a redefinition, since previously it worked via a cast to number (if that can be counted as working) so I am optimistic that the change can be done in place.
12:15	<littledan>	But, Eemeli, can you explain how your position in Shane’s slide deck relates to your current thoughts about what we’ve been discussing in this room?
12:54	<Jesse>	Re strings: oops! That was kind of an unforced error; we added that support somewhat recently, though I guess before we had thought much about how exactly decimal should work. Remember, that was already a redefinition, since previously it worked via a cast to number (if that can be counted as working) so I am optimistic that the change can be done in place. just to make sure I'm clear: do you mean making a normative PR in 402 alongside decimal + measure (whatever form it may take)?
12:58	<littledan>	just to make sure I'm clear: do you mean making a normative PR in 402 alongside decimal + measure (whatever form it may take)? Yeah, that’s what this would be, if we want to pursue it. It’s how we got that string logic there in the first place, back when I was at a much earlier stage in pushing decimal
14:05	<eemeli>	With Measure and Decimal as separate proposals, my sense is that the former answers the question "How do I encapsulate the 'what' separately from the 'how' when formatting numerical values?", while the latter answers "How do I make math work like I expect?" This seems like a pretty effective and orthogonal separation of concerns, and it allows for the proposals to be evaluated separately. In that evaluation, I very strongly support Measure, but I'm skeptical about non-primitive Decimal.
14:07	<eemeli>	With a separately provided protocol for formatting, why does Decimal need to be in the spec?
14:13	<Jesse>	imo measure and decimal are indeed separate beasts (the clearest difference, to my mind, being that arithmetic for decimals should clearly work on day 1 but may not even be necessary for measure, at least not on day 1); I'm neutral on whether they proceed in parallel, or whether they get literally merged
14:47	<littledan>	Jesse explained the use cases of decimal in a bunch of TC39 presentations, and it didn't center on formatting (which is largely already solved by the string support for NumberFormat). Was there a part of those presentations that you found unpersuasive?
14:47	<littledan>	agree on the orthogonality
14:55	<Jesse>	Jesse explained the use cases of decimal in a bunch of TC39 presentations, and it didn't center on formatting (which is largely already solved by the string support for NumberFormat). Was there a part of those presentations that you found unpersuasive? yeah -- the ide was that decimal provide bread-and-butter formatting, like Number, with `toString`, `toFixed`, and `toPrecision`, with serious formatting needs delegated to Intl.NF
16:24	<eemeli>	If we handle the formatting aspects separately and we don't implement Decimal as a primitive, I'm not persuaded that what remains is better than the Decimal libraries already out there, which clearly have been found by many users. The ergonomics aren't improved, and as far as I recall, performance is not presented as a selling point, so what's the remaining value proposition? Why does this problem in particular need to be solved within the spec, when it's already solved outside the spec?
16:37	<littledan>	that is not the use case, that is the functionality. You explained the non-formatting-related use cases for Decimal in your presentations.
16:39	<littledan>	Part of it is similar to the value proposition of Temporal: primarily, these values are passed between different pieces of code (which have trouble coordinating on using the same library), and secondarily, while we're at it, we're doing an especially careful and good job of designing this library, so it levels up the ecosystem.
16:40	<eemeli>	If, again, performance isn't a selling point, isn't a numerical string a really good interchange format for decimal values?
16:40	<littledan>	no, for the reasons that Nicolo explained
16:41	<littledan>	it is a poor interchange format since the second thing people will want to do with them (after formatting) is arithmetic operations, and that will immediately be silently buggy with strings.
16:42	<littledan>	so, this was my question, how should we analyze this concern and come to some kind of shared conclusion?
17:29	<eemeli>	First, it'd be really nice if the proposal repo reflected the benefits of decimal-in-spec over decimal-in-libraries, which is the status quo. At the moment, the spec readme lists three use cases: Representing human-readable decimal values such as money Data exchange [...] with external systems, such as databases and foreign function interfaces to other programming languages Numerical calculations on more precise floats Each of those use cases can be addressed equally well by MikeMcl's libraries. The value propositions that you put forward here don't appear in the readme at all, and neither the FAQ nor the "Known alternatives" sections answer the question "Why not a library?" So could the readme be revised to present the current arguments for the proposal not as if decimals weren't supported at all by the ecosystem, but instead showing how defining Decimal in the spec is an improvement on them? I understand that some of these arguments are certainly included in some of the Decimal presentations, but there's been 11 of those so far, and that's a lot of slides and discussions to look through. I at least look primarily at the proposal repo readme as the source of truth on what a proposal is about, and expect the presentations and discussions to be reflections of some of its aspects. If/as the Decimal readme doesn't seem to answer the questions I have, I may well not think e.g. of your valid point about string "summation" really being concatenation, and not see the value being presented.