- Shane Carr - Google i18n (SFC), Co-Moderator
- Jesse Alama - Igalia (JMN)
- Richard Gibson - OpenJS Foundation (RGN)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Eemeli Aro - Mozilla (EAO)
- Yusuke Suzuki - Apple (YSZ)
- Henri Sivonen - Mozilla (HJS)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
USA: nothing new
SFC: don’t expect much to change (last meeting wasn’t all that long ago). What are we doing to prepare for ES 2025?
USA: We should be more prepared this time. Let’s file an issue to track the different work items. We should aim for the same cutoff as 262 (middle of the year)
SFC: middle of half year
USA: everything else has been solved: Richard made a small change. Aki’s recent work preparing spec for publishing.
SFC: goal for this meeting is to discuss those items. Anything we want to get into 2025 we should discuss. Feb. meeting is the last one. Deadline for stage 4 is that meeting. All PRs should be discussed.
USA: to remind us of normative changes, make a label and use it.
SFC: sgtm, we’ll leave that up to the editors.
EAO: Not a lot from MFWG due to the holiday break. Re-iterating my ask to please review the spec and leave comments there.
SFC: As I have done thus far.
EAO: As you have, thanks a lot for all your efforts. If anyone has had the time to look at it but haven’t commented anywhere officially yet, to comment that would be also helpful for us.
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
YSZ: Nothing yet. My expectation is that most of the things tested through test262 are already done.
SFC: looks like we’ve got good test coverage. What’s not represented in this sheet?
YSZ: I need to go through the table and update it.
SFC: Looks like there are some other issues. Ben isn’t here. Anything from you HJS?
HJS: no
EAO: Couldn’t attend the recent meeting, noticed something in the meeting earlier today about DOM strings. <?>
HJS: I noticed that there's a draft note from the group about string searching, which we've previously discussed.
SFC: Anything in that note that impacts us? Please make sure we cross-reference such items.
HJS: There’s an example from me in the document but I’m not the author of the document. WIll paste a link in the notes. https://www.w3.org/TR/2025/DNOTE-string-search-20250107/
SFC: Wow, this is a full document. What are the APIs?
HJS: e.g. Searching for “jail” might need to find “gaol”. That does not look like a usual expectation for ctrl-f, but maybe web seach engines search like this. What else is like this in the doc?
SFC: Is this document supposed to tweak what happens with Ctrl-F?
HJS: Can’t represent the document, I didn’t write it.
SFC: Thanks for highlighting this.
https://github.com/tc39/ecma402/projects/2
RGN: this has to do with resolving locale (toLocaleLowerCase, toLocaleUpperCase). These exist in 262 with overrides in 402. Unlike localeCompare and collator, which resolve locale based on the first element of an array, collator and localeCompare use valid locale. Not sure what implementations actually do.
RGN: 2nd point: shouldn't be observable. Prefix match versus best match is different from how 402 works.
RGN: no options parameter. Impossible to specify best-fit matching for locales.
RGN: We’ve got a paragraph about how the second two don’t actually matter but the first one is utilized in every conforming implementation.
HJS: I think in principle it makes sense to make things consistent, so it's weird that it uses the first locale instead of the first locale that the engine knows about, so it seems work making that consistent. But it's also good to not over-design this with options. If the only impact this has in practice is "tr" and a handful of others… realistically this is only a boolean of "do it the way 'tr' does". There is a use case but this is just a fancy boolean.
RGN: Okay, remind me if the sharp S is locale dependent.
HJS: there was a discussion about this, triggered by a non-German speaker who raised it for discussion. Triggered a long discussion: What to do about upper-casing the sharp-s in German?
RGN: So in practice given the current data, we’re strictly concerned about turkic locales here. It was probably pointless to have an options bag?
HJS: Having a list of locales is overdoing it. Assume the browser knows about Azeri and Turkish and then use an unknown third one, then fallback to “tr”. The list is there but it’s essentially a boolean.
RGN: To be clear, the list is already supported.
HJS: Currently, in the issue, it makes sense to do what point 1 says. But then point 3 is overdoing things.
RGN: Okay. So IIUC you’d be in favor of a normative change addressing the first and technically doesn’t require any changes for the second?
HJS: I suppose so.
SFC: It might be surprising if from one engine to another, the behavior of this function changed. I think for formatting it makes sense to fall back, but for case mapping, using the root locale is fine. For most locales, the behavior matches root anyway and it’s tailored for exceptions. It seems strange that some browsers would fall back to Turkish but others won’t even though the end result is the same.
RGN: I don’t think that’s right.
HJS: There are more Turkic languages than Turkish and Azeri. So if you have a lesser-known Turkish language like Azeri, you might have a preference list ["az", "tr"] in which case "tr" is the correct fallback. This is use case but not particularly compelling. Compare it to putting “tr” as the 2nd element in the list.
RGN: You want to go to root only upon falling off the list.
HJS: And in this case there’s either root or the Turkic behavior. That’s all.
RGN: if the “zzz” were “en”, then the presence of "tr" doesn't matter.
HJS: Given the fact that we have a list, it should behave the same as in other APIs.
RGN: I completely agree. Concretely, I should put in a normative change with the first two points and leaving the last unchanged.
SFC: I’m reasonably convinced by HJS’s argument, but I’m uncertain. The absence of locale data for formatting is not the same as absence of locale data for case mapping. Maybe the correct thing to do is that, for the browser internally, “az” falls back to “tr”, so “tr” doesn’t even need to be in the list. Not clear that we need to follow the same paradigm as formatters. We have content locale and formatting locales. They get conflated but they shouldn’t. So arguably the logic shouldn’t apply. The behavior we have now: all locales are supported. We don’t read the 2nd item in the list because the algo is different, it’s because all locales are supported. So it’s not inconsistent.
HJS: I understand SFC's way of explaining the behavior. More concretely, I looked at a third example, like "tt". For principled reasons, you don't want to say "tr" because you are dealing with "tt". So you could use ["tt", "tr"]. What might theoretically change this to a non-boolean is if the German discussion ends up with "de-u-something" to change the sharp-S behavior. There are already flags for pre- or post-reform German. There could be another reform. Then de-something-something could opt-in to that. In other words, it’s a boolean for now, but could become three-way in the future.
RGN: That makes sense to me and I think the "tt" example is good. The "zzz" here, by definition, it is unknown whether they should get the Turkic or the non-Turkic handling.
SFC: I guess I’m OK with this conclusion because this is a specific case for case mapping. For collator and segmenter, I’m not sure if we want to apply this convention. The principle is: given a locale, do we know whether it uses the turkik on/off? We don’t want to say: my default locales don’t have that behavior. So if we don’t know, we fall back. Does that seem like a reasonable position to take?
RGN: Okay.
SFC: So Richard, would you like to open a PR by next meeting to bring it to TG1 for ES 2025?
HJS: Actually there is a three-way option. There is Turkic and also Lithuanian ("lt"). And furthermore, the Turkic case… specialCasing.txt explicitly lists "tr" and "az", and none of the three major engines do anything for "tt" at this time. This is in the UCD and not in CLDR.
HJS: There’s a third special case for Lithuanian that all three browser engines support. Furthermore, the Turkic case none of the engines do the same thing for “tt” at this time, since SpecialCasing.txt lists only tr and az. Can’t say how to deal with this wrt specs since this is from Unicode, not from CLDR. Could be considered a reform is https://www.rechtschreibrat.com/DOX/RfdR_Amtliches-Regelwerk_2024.pdf page 48 point E3 prefers “ẞ” over “SS”.
SFC: I don’t think this changes my position on the issue. We should fix the locale resolution algorithm in toLocaleUpperCase etc, but browsers should be allowed to say that locales are supported in case mapping even if not in formatting. Richard’s PR is something we should write.
RGN to make a pull request.
RGN: This is an ECMA 262-style question. Is there appetite for pursuing this for e.g. improving comprehensibility for users/developers? I’m inclined to support this, but if we don’t address it, then the task is to document why we didn’t do anything.
SFC: I think #132 is closely related to this. It’s hard to talk about it without a concrete solution. #132 My feeling here is that I see what Dan is proposing here. There’s one issue where currently we only read options when we actually need to. For instance in NumberFormat we don’t read the currency fields unless the style is currency so this is in conflict with that. There might be a way to have a custom options bag so that getter won’t have to do that expensive thing. Reading options AOT, should we do them in phases? If style is currency then you read certain options but there’s a lot of combinations and this resolution process is very specific. It still won’t solve the ordering problem.
RGN: No matter what, there’s an observable specified order. Right now, it’s emergent and implied. No thought put into it. To resolve this, let’s read in phases. Another way: read a style; having read style, follow up reading everything style-readed. Depth-first vs. breadth-firth. Both are reasonable. And superior to what we’re doing now, with action-at-a-distance. I don’t have a specific algorithm to which to move. I want to be clear, with some reasonable model in mind, going forward and possibly patching up some existing behavior (possibly buggy). What Dan is describing is definitely what I want to move to. There’s a family of approaches that would satisfy this. We don’t need a prescribed order, but we don’t need to follow a particular approach e.g. alphabetic order.
SFC: One worry I have with this approach is that it seems like an unnecessarily large increase in complexity for implementers to do it in this way given that every constructor would have this particular step of reading options and it’s not certain if it’d be read breadth first or depth first. We need to have some rhyme or reason for this observable behavior but is there some good reason to motivate the spec complexity?
RGN: I dispute the categorization as increasing spec complexity. It might make it larger, but not more complex. Definitely less complex, rather. Right now, there are already double reads, that can get different results back. Read a property in one op, move on to another op, read the same property, and get a 2nd result. Asking for trouble. Maybe even in a single implementation. Less complex to read everything up front. If the spec gets bigger, that’s ok. Can’t have significant performance impact, if we preserve your preference to not read properties unnecessarily. When we introduce new properties, we get guidance about what to do.
SFC: Yeah. I’m mainly thinking about: if we have options with a particular name, we need to comb through the spec to see where it’s accessed. There’s three and it sounds like we have a fourth place where we read everything in a particular order. There’s no type checks so this is a recipe for spec bugs. For instance misplaced intermediate objects could cause spec bugs.
RGN: The record doesn’t even have to be intermediate. You can use the value being constructed as the target for the options being read in.
SFC: In many cases, sure, but there are cases such as in Intl.NumberFormat where the options do not map directly to internal slots.
RGN: I’m okay with that. It doesn’t cause any extra work to implementations outside of changing the observable order of things. The consistency that implementations <?> What’s the current observable behavior?
RGN: No matter what, this conversation is about settling on something concrete. Maybe we can have a discussion about what old APIs deviate from that, and whether that should be addressed, case-by-case.
SFC: I think one thing I’d like to see moving forward on this issue would be that you mentioned double reads but I think that we fixed that. If we still have those then we should fix them with normative changes. Once we have that, what we can do is that we can make this structure ahead of time but do it as purely an editorial change. Then we can refactor the spec. Should start with something easy like PluralRules or better, Collator. We can see how much of an improvement it is.
RGN: If it’s an editorial change, it can only be an improvement in terms of spec text. But this is about observable behavior.
SFC: We discussed this in the context of the new options and moving forwards the behavior should be consistent, I have no problems with that. I’m thinking more about if we really want the spec to have two phases in each constructor that’s a bigger step to take. Now that I think about it, a lot of the times we abort reading options until we hit an error. Reading everything before processing would be a normative change. I’m unsure about the spec impact but for future proposals we should think about it a bit more, and we have. If not in alphabetical order, then we allow following a different sensible order like in PluralRules.
RGN: It sounds like this splits into two paths. One is more relevant for new APIs. Not just a pattern to follow, but also how to specify things: a spec reviewer can review it against our guidelines. The 2nd path is trying to apply the same thinking to existing APIs and see how much trouble this causes in terms of spec comprehensibility.
SFC: I like these two approaches. This doesn’t have to block ES 2025 since these are things that don’t need to be in 2025. Updating existing APIs would probably start with editorial changes first so that would take a few months.
RGN: Any normative work here will need runway. Doesn’t make sense for ES 2025. Wouldn’t feel comfortable pursuing normative changes right now.
SFC: I think we’re in agreement then, perhaps we’ve been in agreement all along.
RGN: I like the idea of slicing work into chunks, working on them, rather than giant PRs.
- Pursue guidelines and spec patterns that can be easily checked against the guidelines
- Backport those patterns in editorial changes to existing APIs
- Consider normative changes to existing APIs
USA: They need editorial reviews.
EAO: On LocaleInfo, we discovered two issues. One of the issues was open for a long time and the second one was about week start behavior. Frank was supposed to return to us about those so I assume this would be brought to our meeting before TG1?
SFC: Let’s check the feedback from the last meeting. There are other issues we need to discuss here. Let’s do a quick review since we don’t have Frank here today. Let’s do a quick pass through both of these proposals so we can discuss anything left in there. Let’s take a look at all the open issues in LocaleInfo repo.
Looking at open issues in https://github.com/tc39/proposal-intl-locale-info/
SFC: One thing we did in DurationFormat was to label all the issues so we could find out if something’s v2 or editorial and we don’t have that in LocaleInfo.
tc39/proposal-intl-locale-info#86
SFC: Frank commented on various use cases for minimal days. The problem is that there’s the ISO week numbering system. But Wikipedia says that there are others. Frank reproduced those here. He says these are locale-dependent. Since 2021, Google Calendar has used ISO week numbers in all locales, even in en_US, which should use different week numbers. Reason: users were presumably complaining “why are my week numbers different someone elses”. Solution: ISO week numbers are used uniformly. minimalDays does not impact that. Since they made that change, that’s evidence: do we need to have this? Maybe the answer is “no”. Locale first-day-of-week is important. But locale-based week numbering is unclear to me.
EAO: I agree. Only place where week numbers are used in JS is in Temporal. After Temporal, we’ll only support ISO week numbers. Given that, it would be misleading to present something about minima days that potentially doesn’t match what the user gets when operating on week numbers in JS. Which is envisioned as happening only in Temporal. So we see the possibility for misleading people.
HJS: As mentioned the last time, the HTML type weeks only accepts ISO weeks since the use cases are driven by European businesses who tend to care about this.
SFC: The impact then is that we expect for this minimalDays to not be included in the Intl.LocaleInfo proposal. How does it affect the runway for stage 4? Can we have a normative change right before going for stage 4?
EAO: I do believe we ought to have implementations of the spec, not a previous version of the spec, before we call it stage 4.
HJS: I would also like to see the issues Anba filed addressed before Stage 4.
SFC: ES 2024 didn’t have any Intl proposals in it and ES 2025 will have one proposal in it: DurationFormat. It seems Intl.LocaleInfo isn’t ready there haven’t been activity. There’s a PR here which I need to approve that’ll fix the issues that Anba filed.
SFC: Two issues are spam. I can’t close them.
SFC: Normative PR open since August, haven’t discussed? I will follow up with Frank when he gets back.
USA: I closed the two spam issues.
SFC: Safari and Firefox have implemented DurationFormat but not Chrome, is that right? Let’s ping all implementers to see what they do. I believe this is a spec bug and not a normative change. We should fix the spec bug soon.
EAO: Nothing to share. I’m preparing an update for the next meeting.
tc39/proposal-intl-currency-display-choices#3
SFC: One open issue. There’s very little data about this in CLDR. Time, money, dollars. The intent of this proposal is “US$” rather than “$”. Given that there’s no data for this in CLDR – maybe there should be! – I think we should see this land in CLDR first.
SFC: process-wise, just as a note, this proposal was reviewed in this group in December and we approved it for Stage 1 but never for Stage 2. It got to Stage 2 a lot faster than I expected it to.
EAO: The data sort of is in the CLDR. Just not directly. For US dollars, it is there in en001. Data for USD in en_US says “$” and narrow symbol is “$”. This is what causes the issue of always getting just “$”. But we can see these are the strings to use for symbol and narrow symbol. In parent locales, we get (looking in en001) we have the symbol defined as “US$”. This could be used as the value for the formal symbol, in en_US, based on data in CLDR. Admittedly, it involves looking up data indirectly. Also possible that in the cases I’ve inspected, there may be cases that this kind of resolution algorithm produces a weird result in CLDR. I agree that the data should be presented better, but it is there.
SFC: It’s great if it’s there already. The place to have that discussion is CLDR perhaps in a ticket and adding a section on UTS35. It’s only with that where we can define an algorithm like this for currency resolution and it needs to be implemented in ICU and then we can discuss it in TG2. It should be motivated in the opposite direction.
EAO: I’m not sure I agree that this is the order of operations. Here, in Ecma 402, we’re end users and we’re expressing a desire to have an API. We ought to be having conversations in the ICU context. I agree that this is a stage 2.7 blocking concern.
SFC: Stage 1 vs 2: it’s a way for us to signal that this is something we want to see. I would have guessed a stage 1 proposal would have been sufficient for other audiences. It does make sense to have a proposal at a low stage to motivate work with CLDR. Maybe there’s no real disagreement. I haven’t had this issue…no plans to work on this issue. If you want to work on it, if you want me to work on it, we need to clarify next steps.
EAO: CLDR issue on this: regarding stage advancement, I agree that we did, in the meeting, talk about stage 1, but when I filed the issue with the TG1 agenda, it was there as stage 2. I posted this on the matrix channel and got thumbs up from two editors. So it looked like I had a decent amount of support for this proposal.
SFC: Understandable, but a bit regrettable due to holidays in the US. What you did is sound. Let’s not be overly conservative. I was surprised to see a stage 2 on this. To see it approved for stage 2 was surprising. But it’s fine. We both understand why that happened.
SFC: If you can post your thoughts on this issue…
EAO: I will.
SFC: I’m going to add that to one of these upcoming CLDR design meetings.
EAO: I don’t have a ton of bandwidth to work on this but the other thing I’m working on is already in that loop, it is Message Resources.
SFC: This is all we needed to discuss on currencyDisplay.
EAO: Noting also explicitly that one of the main drivers of raising this issue was that this option was added after a lot of discussion in the MessageFormat WG. SInce the syntax for number and numeric formatting is very influenced by the 402 behavior, it’s desirable to know if the names of these values are appropriate before they get standardized in MF2. JS shouldn’t have conflicting option names. If we have any concerns we would love to address it.
SFC: My feeling on the naming of formalSymbol is that I just want to follow what CLDR calls that symbol. It already has the narrow name it’s fine to use the formal symbol.
USA: What is the Ecma 402 name for it?
EAO: What we are proposing as “formal symbol” has no well-established name. Taiwanese dollar in traditional Chinese. Calling this thing “formal symbol” is based on prior art, and a decent description. Alternative: “wide symbol”. We have options “symbol” and “narrow symbol”. This would be a third one. The “wider” option you might or might not get if you ask for just a symbol.
USA: Is there a code in currency display?
SFC: We could call it “medium symbol”.
EAO: “Medium symbol” is confusing because there’s nothing wider than a wide symbol. So maybe better is "wideSymbol".
EAO: Is there a preference between “formal symbol” and “wide symbol”?
RGN: I’m slightly inclined towards wide just for fitting into the existing scheme. Medium also fills that goal if we feel that way. It contrasts well with “narrow”.
SFC: I don’t think we use the word “wde” anywhere. We say “long”. In DateTimeFormat we use the word “long”. We don’t like “wide” because it talks about the width of the text. So “long” would be another option to consider.
RGN { “short”, “narrow”, “long” } is the set of values for a number of options.
USA: Since we have short and long, I guess medium would be perhaps an easier choice, because then it doesn't need to conflict with our scheme? It seems weird to have "wide" for one function.
EAO: We are consistently talking about a prefix before the word “symbol”. So “narrow symbol” in full.
SFC: “Formal symbol” and “long symbol” should be our options. Let’s make an issue.
EAO: Part of the next step on this discussion is to raise the awareness of this to the CLDR design team. That does have the formal symbol defined for that particular case. Given that the data is there if you start looking at it in a different way to fallback in the usual lookup so let’s see how we can rename this sort of fallback value.
SFC: To contract slightly with what I said earlier if CLDR chose to use formalSymbol we could still use longSymbol. Depending on the strength of their naming. One thing could be to decide the naming the fields and encoding that somewhere in the spec.
EAO: MessageFormat is a place where the naming becomes quite important. If we have a process that takes longer on this, I’ll ask the MF working group to drop “formal symbol” so we don’t have a conflict. We identified this only as a need for a particular edge case.
SFC: Should be changed to “status proposed”. I support changing this to “proposed” instead of “required”.
USA: I think it might be a good idea, given that we're still talking about this, but I think "formal symbol" isn't a bad name for us. It doesn't conflict with our existing naming scheme. Perhaps since we already have code, we could relate it to that somehow.
JMN: Ben planned to go to Stage 0 but got Stage 1 for Measure. There is an overlap between the two proposals. My current proposal is to unify the two proposals. The idea behind Measure is about a number+unit record alongside precision (or dimensionless things) also discussions about currencies and other measurements of physical things etc. The precision is important in these cases. This is yet another case where the long standing topic of precision comes back to this group. We’ve gone back and forth on this topic. We’ve settled on in the most recent update in the meeting in Tokyo we discussed IEEE754 and Decimal 128 and how precision works collectively for these two. Representing MVs is the best option even though we can have high precision. I think these two things are talking about the same idea foundationally. Measure is talking about numbers, perhaps tagged with a unit and Decimal is talking about the same thing about numerical values with precision. We need to think about them together. Can’t say what they will be called together but they will be intertwined. One thing I want to discuss here if we think what I’m proposing is plausible. Can we have three classes here or two. One vision can be with a two class approach which would be Measure and Decimal. The thinking is that Decimal would represent normalized values i.e. MVs and measures could be constructed using JS numbers, digit string or decimals. There would not be a lot of overlap. An interesting alternative would be the three class approach. We would have not just decimal and measure but full non-normalized decimals as well. There would be a traditional Decimal128 implementation and Decimal would represent the normalized value and of course Measure. The underlying value of Measure would be a decimal there since measure needs to rely on this anyway. I also intend to bring this idea to TG1 in a few weeks.
SFC: Thanks Jesse for the update. I’ll say first that as Jesse knows I’m generally in favor of this direction. Some details can be clarified but I’m happy. One thing Ben had proposed was the idea that Measure has a pluggable numeric type. but in this proposal it is always a Decimal. Just settling on Decimal would be cleaner and easier to implement, but there was support on a pluggable type from some folks from this group.
EAO: So, my sense is that if we leave the precision part out of decimal. If we consider decimal to be representing a numeric value, then what we’re left with is two proposals which are orthogonal. You use measure by using a numeric value that you wrap with a unit or a currency or possibly a precision and this is a unified whole thing to work with. From that POV, it’s going to be very surprising in the value in this measure from the value that you gave it. If I constructed a value with the number 42, it’ll be awkward to get a decimal out of it. Likewise with other types. The possibility would be that you always get a decimal out of it. I don’t see the value in that rather than conserving the original value. If you take that out then the separation between the proposals and the way they interact with numberformat becomes much more cleaner. Measure makes measure values formattable, no matter what the underlying store is although decimal can be about the decimal data model.
SFC: There’s a few ways to look at it. One is that it’s just an interface to carry a unit along with a value that MF needs. It’s just an interface and that’s one way to look at it. The other way is to think of a new way to represent measured quantities not only for Intl but also for 262. It’s acknowledging that there’s a use-case for measures not just for formatting but also in general. I like that we’re introducing a type to actually represent things. We’re moving in a world where Intl operations are more transparent. Temporal does this with its new types where they bring both things together. Temporal’s approach is a cleaner one and therefore it’s better for the web platform. By separating these two, we step away from having this opportunity to embrace this Temporal-like data type in the language. Regarding bigint in and bigint out then nothing in the spec removes the ability to do that. It doesn’t remove the ability but the whole point of Decimal 128 is that it covers every single use case we have and BigInt formatting is actually overkill for our use cases. The use cases being covered by Decimal 128 by itself makes us not rely on BigDecimal <?>
JMN: These things can be thought of as separate proposals; the mechanics could be merging proposals or advancing them in tandem or a multi-stage approach to these things. If you have a BigInt and you get a Decimal, I agree that seems bad because of data loss. BigInt in, BigInt out, Number in, Number out. But maybe instead there can be a conversion function.
EAO: In terms of proposal structure, they are absolutely related to each other. It's entirely plausible that there would be tooling for getting a Decimal value out of a Measure depending on what you put in. But structurally, it feels like proposals around modules. There's a tree structure that are part of a bigger whole. But concerns about Decimal are identifiable as concerns about Decimal and same for Measure. There is some overlap, but considering all of the issues in one context gets loud. But yes, coordinated with each other.
SFC: Yeah, just to reiterate what I’d just said. One reason (I gave a presentation about this in Dec) I think it’s important to look holistically about what the approach should be. We do a pretty bad job in TG1 at sort of looking at these big groups of proposals. We should do a better job at handling how numeric types work in JS. Introducing a decimal data type as well as another data type to handle quantities of measurements. Addressing those in a single way consistently in a way that’s good for users is why I think they should be looked at the same time together. I think it’s not healthy for the measure champions to work in isolation. I think it’ll be a better outcome to think about the outcomes for both of these. They can advance as separate proposals. I’d like for them to be coupled at Stage 2. I’d like them both to advance to stage 2 in the same meeting. I don’t want either proposal to be left behind. It’ll be a better outcome if we couple these two proposals together like this here. The champions can be independent but we can still consider them together.
EAO: I get your point, not sure I agree with this idea of interlinking these two proposals together. Effectively I believe in Measure being a really good idea. I can’t say the same about Decimal at this moment. It can’t be a primitive so there’s suboptimal ergonomics. I can’t see Decimal being as strongly motivated in the current shape. I’m not the only person looking at these two proposals who has different use-cases in mind. There’s some overlap but there’s also vast differences in the use cases as well as how these proposals can be employed.
SFC: My position for a long time has been that the motivation for the Decimal proposal is even stronger when it is considered in the Measure universe. If we advance Measure as a thin interface with a generic numeric type, I think the motivation for Decimal is relatively weaker.
USA: To add, in any universe where Decimal ends up happening, it would be one of our important windows to unify these. If we do Measure before Decimal, and we do it with different numeric types, and we add to that matrix, we're losing the train for unification. It makes Measure less motivated… it makes it so you want to wait out what happens with Decimal.
EAO: Looking at issue 185 in Decimal, it would be good to find the synthesis between the proposals. If we were to consider these as a unified whole, what are the benefits we get? That needs to be better presented.
JMN: Yes, sounds good. Challenge accepted.
SFC: Yes, I've long thought that the whole is greater than the sum of the parts. We need to make that more clear.