Editorial: Simplify NumberFormat

[gibson042]

• Collapse rounding mode negation data into one table.
• Fold GetUnsignedRoundingMode into ApplyUnsignedRoundingMode

[ptomato]

Would you have time to update the usages of GetUnsignedRoundingMode and ApplyUnsignedRoundingMode in Temporal while this is still fresh?

[gibson042]

Hmm. I quite like having a clean separation between RoundingMode (what users specify) and UnsignedRoundingMode (what implementations need).

I might agree with you if we didn't make comparisons against the former all over the place, including in many steps in or downstream of NumberFormat PartitionNumberPattern (numberFormat.[[Style]] vs. "percent"/"unit"/"currency", intlObject.[[TrailingZeroDisplay]] vs. "stripIfInteger", numberFormat.[[SignDisplay]] vs. "never"/"auto"/"always"/"exceptZero"/"negative", numberFormat.[[Notation]] vs. "scientific"/"engineering"/"compact", etc.).

I'm not convinced that essentially replacing the internal enum UnsignedRoundingMode with an internal tuple that pairs RoundingMode with ~positive~ or ~negative~ is an improvement.

Well, that's exactly what GetUnsignedRoundingMode does right now. The benefits of instead directly propagating that pair into ToRaw{Precision,Fixed} and ApplyUnsignedRoundingMode are

• Make clear in the definition of rounding modes that only the ceil/floor family need this adjustment when working with absolute values, defining details about the rounding modes in one place.
• Avoid essentially duplicating that table a huge distance away.
• Avoid needless introduction of new entities that basically duplicate the rounding modes anyway.

[sffc]

Just as an anecdote, we found the UnsignedRoundingMode enum useful when implementing ICU4X, and we include it along with the conformance table in the docs.

https://unicode-org.github.io/icu4x/rustdoc/fixed_decimal/enum.UnsignedRoundingMode.html

[gibson042]

https://unicode-org.github.io/icu4x/rustdoc/fixed_decimal/enum.UnsignedRoundingMode.html

I don't have the context to evaluate how (or if) that might be different if the spec had already looked like I'm proposing in this PR, but the "Comparative table of all the rounding modes" at that link includes all 9 user-specifiable ECMA-402 rounding modes and not the current spec enum values produced by GetUnsignedRoundingMode (which makes sense, because the latter are redundant with the former—INFINITY/HALF-INFINITY is just "{ceil,expand}"/"half{Ceil,Expand}", ZERO/HALF-ZERO is just "{floor,trunc}"/"half{Floor,Trunc}", and HALF-EVEN is exactly "halfEven"—due to the respective equivalence of "ceil" vs. "expand" and "floor" vs. "trunc" when limited to non-negative input).

[gibson042]

There are two parts of this PR. The first 4 commits look fine to me. I would approve those as a separate PR.

#983

[sffc]

https://unicode-org.github.io/icu4x/rustdoc/fixed_decimal/enum.UnsignedRoundingMode.html

I don't have the context to evaluate how (or if) that might be different if the spec had already looked like I'm proposing in this PR, but the "Comparative table of all the rounding modes" at that link includes all 9 user-specifiable ECMA-402 rounding modes and not the current spec enum values produced by GetUnsignedRoundingMode

The spec table is in terms of the signed rounding mode because that is the table in the spec. It should probably be on the signed rounding mode enum in the docs. The docs themselves acknowledge this and link back and forth between the rounding mode enums.

---

My qualm is that, based on implementer experience, both recently and less recently, floating point and decimal numbers (the types NumberFormat deals with) are stored unsigned, with a sign bit on the side. So as far as we are concerned, there are only 5 rounding modes, the unsigned ones.

This insight is not obvious, which I think makes it even more useful to be included in the spec.

[sffc]

A short TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-08-14.md#editorial-simplify-numberformat-978

[sffc]

More TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-09-11.md#editorial-simplify-numberformat-978

[sffc]

We've agreed on a path forward that improves this PR. @gibson042 intends to push a fix.