Case convention of rounding modes

[littledan]

From #7: It's interesting to see the case conventions of halfEven instead of half-even. This matches our recent decisions. Unfortunately, now we're getting into an area where this convention potentially "infects" or conflicts with the other convention, where it would be half-even: I was hoping that Decimal would use rounding modes that match Intl. Do we want to extend the camelCase string convention here?

[sffc]

FYI, the style guide documenting the camel case convention is here:

https://github.com/tc39/ecma402/blob/master/docs/style-guide.md

[littledan]

Thanks for the cross-reference. I agree that using names like halfEven follows our current convention. The implication/interaction with Decimal is the part that I hadn't thought through yet, and what I wanted to discuss in this issue.

[sffc]

Given the established style in 402, if the Decimal proposal wants compatibility, the easiest thing is to just use the camel case convention in the Decimal proposal. Otherwise, someone could make an argument that kebab case is better than camel case, and then we can consider breaking from the 402 convention in the NumberFormat V3 proposal.

[littledan]

I don't know what the right answer is here. I just don't think we had considered a case where compatibility here bled into ECMA-262, so it'd probably be worth some explicit discussion.

[sffc]

When we discussed this topic at TC39, I had first proposed that we adopt this style across both 402 and 262, but I got pushback along the lines of "we haven't thought this through enough to make a blanket recommendation for 262". So, instead, I got sign-off from TC39 to adopt this style in 402, with the expectation that it may bleed into 262 at some point in the future, at which point we could discuss it again. That time seems to be now, arriving sooner than I had been expecting. 😉

[littledan]

It's sooner than I expected, too. I'm not comfortable with adopting this convention 262-wide.

[sffc]

@littledan, are you okay with this proposal proceeding with the camel case names, or would you rather hold this feature back until it's time to put it in the decimal proposal, at which point we could discuss having a different casing convention?

[littledan]

Delaying this feature is a pretty complicated question. One factor is, I still owe you more references that led to this feature request (I'm not sure if we've gotten independent requests). At the same time, I don't think we should hold back this feature for decimal's timeline, which seems slower. Overall, I hope rounding modes can match decimal, but I think we could decide ahead of time that we can go back and "harmonize more" as part of a future decimal proposal:

• Names of rounding modes: I think it's OK to move ahead with camelcase names now as long as we're OK with the possibility of, in the future, additionally permitting kebab-case names to be parallel with decimal (if decimal goes that way).
• Set of rounding modes: I think it's OK to go ahead with a minimal set of certain modes here as long as we're OK with expanding that set for parallelism with decimal.

I doubt we'll come up with a mismatch where a name is completely wrong or the semantics are wrong; there isn't much room for bad decisions here.

[sffc]

To skirt around this issue, my latest proposed rounding modes in #7 (comment) are one word each. I will close this issue if we have consensus on #7.

[sffc]

According to #7, we are moving forward with camel case (halfEven, halfExpand, ...).