| 07:29 | <Jesse> | do we want Amount to support NaN, -0, and infinity? |
| 07:29 | <Jesse> | thinking about measurements or financial quantities, I think you could say that all of those shouldn't be there |
| 07:34 | <Jesse> | we could easily support those since decimal supports them. Intl also supports them, so we'd be on solid ground. But we can nonetheless ask whether amount should support them |
| 07:36 | <Jesse> | if we do support NaN etc. do also want Amount to have predicates like isNaN etc. that decimal has, or do we require the user to query the underlying decimal? |
| 08:05 | <nicolo-ribaudo> | if we do support NaN etc. do also want Amount to have predicates like x.decimal.isNaN() is fine |
| 08:06 | <nicolo-ribaudo> | Does the IEEE spec allow defining things like "infinity with a precision of 3"? |
| 08:07 | <nicolo-ribaudo> | For -0 I think it makes sense to support it. -0.0 and -0.000 seem to me like different numbers (the first one is less than 0 and more that -0.005, the second one less than 0 and more than -0.0005) |
| 08:11 | <Jesse> | in IEEE there's no precision for NaN or the infinities |
| 08:11 | <Jesse> | but there is precision for -0 |
| 09:18 | <eemeli> | Are example non-formatting use cases for decimal-with-precision available anywhere? I can only find a wrapper for IEE754 precision propagation in nicolo-ribaudo's proposal-numeric-with-precision, but nothing e.g. within the proposal-decimal repo. I think the formatting case for a decimal-with-precision is quite clear, but if the intent is to not have that as the only reason for something like Decimal.Amount, then I think the we ought to say something a bit more that the presentation's current assertion:
Is that an actual demonstrated need, or a theoretical one that might exist? |
| 09:39 | <Jesse> | those use cases in N-ic's proposal should be integrated into decimal; much of the thinking there maps over into amount |
| 09:44 | <Jesse> | looking ahead (or sideways?) to the measure proposal, the need to have all digits is more clearly motivated |
| 09:46 | <Jesse> | if one temporarily ignores measure, the need for out-of-the-box round-trippability is a nice invariant |
| 09:48 | <Jesse> | btw "amount" is currently not the best name; I've updated the slides to use a placeholder name |
| 09:48 | <Jesse> | suggestions welcome |
| 09:49 | <Jesse> | we've thrown around a few ideas here but haven't really settled on one |
| 12:38 | <eemeli> | What does this mean? What's the use case here? |
| 12:41 | <Jesse> | something like Decimal.Something.from(x, 3. "fractionalDigits").toString() === x for all digit strings x with 3 fractional digits (where 3 is known out-of-band) |
| 12:44 | <Jesse> | this could be used for e.g. currency, where a number of fractional digits is known in advance |
| 13:07 | <eemeli> | If that's important in particular for currency values, then we ought to be quite explicit about it, as this has significant implications for the .toString() output once we start to consider including a currency field as a part of proposal-measure. |
| 13:13 | <eemeli> | As in, I think it means that either:
Presuming, of course, that we agree that this sort of round-tripping is important. |
| 13:15 | <eemeli> | Hence my question earlier: Is there an actual demonstrated need for non-formatting use cases for decimal-with-precision that is significant enough that we need to account for it in this API design, or do we only strongly care about the formatting use cases? |
| 13:16 | <littledan> | I'm having trouble following; are we proposing having a parser for Decimal.Amount? |
| 13:17 | <littledan> | let's follow the decision for Decimal. The counterarguments are the same in both cases. If we're going with it, let's stick with it for Decimal.Amount |
| 13:17 | <littledan> | the most visible usage of a name is on the title slide; you might want to change that |
| 13:17 | <eemeli> | I don't think we ought to have one, but if we seriously care about round-tripping, then that's something we need ot consider. |
| 13:18 | <littledan> | my understanding was that the driving motivation was around the formatting use case |
| 13:18 | <eemeli> | That's my understanding as well, but e.g. the slides first mention the non-formatting case. |
| 13:18 | <Jesse> | atm there's no parser for Decimal.Something; using the .from static constructor method, the 1st argument is a decimal string, which gets passed to Decimal, which does have a parser |
| 13:19 | <littledan> | where did the demand for round-tripping come from? |
| 13:19 | <Jesse> | it's mentioned in the issue which kicked off this disucssion: https://github.com/tc39/proposal-measure/issues/26 |
| 13:20 | <Jesse> | it's not the topmost need, but it is there |
| 13:21 | <Jesse> | we can focus on the value Decimal.Something has for i18n -- that's the clearest benefit |
| 13:22 | <littledan> | hmm, do you have the .equals method? |
| 13:22 | <littledan> | (I don't really know what the use case is for that) |
| 13:23 | <eemeli> | Hang on, how could we even have round-tripping unless we have a parser that parses something like '1.20' as something more than just the decimal value 1.2? |
| 13:23 | <Jesse> | we had it, but dropped it because the use case wasn't exactly clear, and it becomes easily user-definable if we expose the underlying value and precision |
| 13:23 | <littledan> | I don't see anything on that thread about round-tripping parsers |
| 13:23 | <littledan> | let's keep this simple! |
| 13:24 | <littledan> | as minimal as possible |
| 13:24 | <littledan> | just because we can vaguely conceive of a use case for something doesn't mean we should have it |
| 13:24 | <eemeli> | And to therefore explicitly not aim to support round-tripping, or other non-formatting use cases for decimal-with-precision. |
| 13:24 | <littledan> | I guess the from method is the parser? |
| 13:26 | <Jesse> | yeah, .from is the parser (though I might say that from contains the decimal parser) |
| 13:26 | <Jesse> | for .from, I have in mind taking 3 arguments, no just 1 (a decimal string) |
| 13:27 | <Jesse> | I could imagine it taking 2 (a decimal string and a "precision mode", indicating either fractional digits or significant digits) |
| 13:27 | <Jesse> | but certainly more than 1 |
| 13:28 | <eemeli> | I continue to prefer not having a .from factory method, and using new Amount(value, options) where the value is parsed as the numerical value and the options may initially contain fractionDigits or significantDigits, and be later extended to also support unit and currency. |
| 13:30 | <Jesse> | we could certainly go either way -- I'm agnostic about that. I think the idea for a static constructor method came from Temporal. But there, we also have new, too |
| 13:31 | <littledan> | yeah I guess my preference for making this absolutely as minimal as possible is fairly soft |
| 13:31 | <littledan> | I was just surprised that this was part of it |
| 13:31 | <eemeli> | If new Decimal(value) works with numbers, strings, and decimal values, then I would find it quite surprising for the same proposal to advocate a different approach for Decimal.Something. |
| 13:34 | <Jesse> | tbh I think we didn't quite have this full discussion for decimal -- values were understood as constructed using new, only. There was some discussion of having explicit conversion methods (toNumber, toBigInt) but IIRC we didn't make a decision about whther to have factory methods. We ended up just stuffing everything into the constructor, taking many possible types of arguments |
| 13:35 | <Jesse> | I might suggest this as a topic for discussion in the next champions call next week |
| 13:36 | <Jesse> | Shane hinted at a broader topic in the last call, namely whether Temporal-style design (especially concerning constructors) is something we want generally, in TC39; but IIRC we didn't apply that thinking to Decimal |
| 13:37 | <Jesse> | MM's question yesterday about membranes and static methods makes me wonder if we should ban the Decimal constructor from taking a Decimal |
| 13:37 | <Jesse> | this is a bit edge case-y but that may come up |
| 13:41 | <eemeli> | If the Decimal constructor can't accept a Decimal value, how should one copy a Decimal instance? Also related: If you construct a Decimal.Something with a Decimal value, is the Decimal.Something value the given instance, or a new instance? This matters in particular because Decimal is a class which may be extended. |
| 13:41 | <Jesse> | one way to copy x would be new Decimal(x.toString() |
| 13:43 | <Jesse> | for constructing a Decimal.Something from a Decimal x I was thinking: new Decimal.Something(x.toString(), n, "fractionalDigits") where n is something known out-of-bounds, as is "fractionalDigits" (the knowledge of how precision to be understood) |
| 13:43 | <Jesse> | you could also do e.g. new Decimal.Something(x.toFixed(n), n, "fractionalDigits") or new Decimal.Something(x.toPrecision(n), n, "significantDigits") |
| 13:44 | <eemeli> | Huh, and after yesterday: should a Decimal value be a Composite with a custom prototype? If it's not, how else could one use a Decimal as e.g. a Map key? |
| 13:47 | <Jesse> | imo we should try to align Decimal with Composite -- what do we need to add to the prototype? |
| 13:48 | <littledan> | I think it's premature to align Decimal with Composite |
| 13:48 | <littledan> | anyway you wouldn't change anything about the prototype, just make it a frozen object |
| 13:49 | <littledan> | (not frozen prototype but frozen instance) |
| 13:49 | <Jesse> | agree it's early days for the composite discussion |
| 13:50 | <littledan> | if you're saying Decimal should be a Composite, you're saying one thing should block on the other, and I'm not convinced |
| 13:51 | <eemeli> | One relevant part is that I think we can agree that Decimal.Something is not expected to provide a custom equality. |
| 13:52 | <Jesse> | based on the understading of equality Shane sketched in the issue, I think it's not necessary |
| 13:52 | <Jesse> | but if there's something we've overlooked, I'm happy to hear it |
| 13:52 | <littledan> | custom? |
| 13:52 | <Jesse> | I'm happy to drop that and keep decimal.something really minimal |
| 13:53 | <Jesse> | there are probably some Intl needs for equality that Shane had in mind that we could dive in to |
| 13:53 | <eemeli> | As in, a built-in way to specifically say if two somethings are equal. |
| 13:54 | <eemeli> | Is there pre-existing discussion on whether a non-primitive Decimal ought to be usable in a Set or as a Map key? |
| 13:54 | <littledan> | maybe we can just keep this presentatlon slightly ambiguous, and focus on talking about the minimal core, and see if people are up for that? then we can argue about details |
| 13:54 | <littledan> | sffc: this would be helpful; Waldemar seemed to oppose this particular equality operation strongly |
| 13:55 | <littledan> | I haven't seen discussion about this. The assumption has always been that it'd be a normal object |
| 13:55 | <littledan> | OK, so just the equals method. |
| 17:05 | <nicolo-ribaudo> | Note that equality is trivial to do in userland |
| 17:05 | <nicolo-ribaudo> | `x.decimal.equals(y.decimal) && x.significantDigits === y.significantDigits` |