Add conclusion to decimal presentation

meetings/2024-10/october-09.md

@@ -641,7 +641,7 @@ SFC: Great, yeah. Thanks for the presentation, JMN. I had another item that disa
 
 NRO: I think if you wanted to drop the primitives in the future, we should be—I mean, it’s a world in which we don’t have two different decimals. Where one is just, like, not just—like, the object wrapped around another. Because that will be a trigger for numbers in the language. And while today we don’t see a way to have primitives, I would still like to consider that possibility to be realistic one day, and having two different decimal types is just, like, not something that I wish for JavaScript to give us.
 
-SFC: Yeah, I don’t mean to have all my topics right next to each other, but, yeah, I mean, I would like to see these proposals, like—it—I don’t want to be in a situation where we base—like, where like, you know, the champions of this proposal basically said, like, oh, we have this other possible approach for numerics with precision, you can go solve it this way, go, SYG, get out my way, I’m wanting to move—force my way forward with this decimal proposal in a way we know doesn’t satisfy your requirements. I don’t want to be in that situation. I want to be in a situation where we have—where we’re introducing into the language a, you know, well-rounded solution to how you represent decimal numbers, right? And, you know, that—where we really think about the big picture. Because if we—if we force through this weird decimal object thing that’s designed for a possible future primitive, like, you know, like, what does that mean for, you know—for the—the ability to represent precision and other—you know, its impacts on insill. That seems silly on its face. So, like, if we want to move into this direction of having two objects, I wanted to see those coupled. I don’t want to see at some some future stage proposal, I want to see that together in one slide, like, here is how you can do these things, so that’s my next topic.
+SFC: Yeah, I don’t mean to have all my topics right next to each other, but, yeah, I mean, I would like to see these proposals, like—it—I don’t want to be in a situation where we base—like, where like, you know, the champions of this proposal basically said, like, oh, we have this other possible approach for numerics with precision, you can go solve it this way, go, shoo, get out my way, I’m wanting to move—force my way forward with this decimal proposal in a way we know doesn’t satisfy your requirements. I don’t want to be in that situation. I want to be in a situation where we have—where we’re introducing into the language a, you know, well-rounded solution to how you represent decimal numbers, right? And, you know, that—where we really think about the big picture. Because if we—if we force through this weird decimal object thing that’s designed for a possible future primitive, like, you know, like, what does that mean for, you know—for the—the ability to represent precision and other—you know, its impacts on insill. That seems silly on its face. So, like, if we want to move into this direction of having two objects, I wanted to see those coupled. I don’t want to see at some some future stage proposal, I want to see that together in one slide, like, here is how you can do these things, so that’s my next topic.
 
 SFC: And I have yet another topic. Sorry, I didn’t mean these all to be back to back. There were people in between me and they all left the queue, so I have my topics back to back. I apologize for that.
 
@@ -661,7 +661,7 @@ JMN: Yes, that’s right. And I take SFC’s point that—as well that this migh
 
 NRO: Yeah, so the proposal is not designed to behave exactly as the object of a primitive. Like, it behaves exactly like the number object, for example, except it has the various prototype methods. In another potential world that was the idea was pushing back against earlier where we have some type of decimal object now, and we say that doesn’t actually preclude us from having a primitive, the future primitive, just a different way. Like, something unrelated. I believe that’s the, like, worldview that you might consider to be just designed to not conflict with a primitive. While the one now, where we—the one I was, like, it’s designed to fit nicely with the decimal primitive.
 
-SFC: So, yeah, my next topic, so, you know, I appreciate that, you know, JMN and NRO have been, you know, trying to assuage my concerns with this over numerics with precision. But I just want to emphasize here, and I haven’t, you know, in my discussions with NRO and JMN and other, I haven’t really heard these topics be addressed, that, like, this the not just an Intk concern about precision. This concept of being able to represent, you know, the numbers with variable levels of precision has many other use cases, and I’ll just list a few here. So one is, you know, when we look at, you know, precedent in other decimal libraries and other languages, it’s, you know, basically the standard that, like, every other decimal or big decimal library you find in another programming language support this concept, and it’s been that way for a very long time. And given that—given that precedent, it means that, you know, I think JMN sort of—I very much disagree with the slide about halfway through that said, like, the 1, 2, 3 with big green check boxes. That’s just patently false, because we cannot round values to these other platforms if we don’t support precision in the data model.
+SFC: So, yeah, my next topic, so, you know, I appreciate that, you know, JMN and NRO have been, you know, trying to assuage my concerns with this over numerics with precision. But I just want to emphasize here, and I haven’t, you know, in my discussions with NRO and JMN and other, I haven’t really heard these topics be addressed, that, like, this the not just an Intl concern about precision. This concept of being able to represent, you know, the numbers with variable levels of precision has many other use cases, and I’ll just list a few here. So one is, you know, when we look at, you know, precedent in other decimal libraries and other languages, it’s, you know, basically the standard that, like, every other decimal or big decimal library you find in another programming language support this concept, and it’s been that way for a very long time. And given that—given that precedent, it means that, you know, I think JMN sort of—I very much disagree with the slide about halfway through that said, like, the 1, 2, 3 with big green check boxes. That’s just patently false, because we cannot round values to these other platforms if we don’t support precision in the data model.
 
 SFC: We just get—yeah. yeah, if you can go to that slide . It’s a slide with three little check box emojis on it. Yeah, this one here (https://notes.igalia.com/p/tc39-decimal-october-2024#/10). Okay, so on the second bullet point, like, might be problematic in some cases is just a—is just a way of saying, it does not actually work all the time. And if it does not actually work all the time, it does not round trip. It round trips or doesn’t. It’s black and white. It’s not a gray area. It does not round trip, that’s just objectively false. So that should not be a check mark. Right? So regarding the first one, human produced numeric quantities, like, you know, the Intl example that you showed shows that this is also patently false. This should not be a check box because it’s clearly false. And, yeah, we could—we don’t have to get into argument about that right now. But, like at least these first two bullet points, like, those are absolutely not check boxes. They should not be check boxes.
 
@@ -708,6 +708,11 @@ SFC: Yeah, I just warranted to fully with what you just said Jesse. Stating the
 - The Decimal champions propose a spinoff proposal for “numeric value with precision” that can address different ways of encoding precision
 - The decimal champion group believes it is close to asking for stage 2
 
+### Conclusion
+
+- Feedback was expressed that it is unclear whether the current design, with canonicalized decimals, meets the stated needs of the proposal.
+- The champion group will iterate on the current design and clarify the relationship between it and the newly proposed [measure](https://github.com/tc39-transfer/proposal-measure) proposal.
+
 ## ArrayBuffer construction step order
 
 Presenter: Richard Gibson (RGN)