Drop rounding mode options

[eemeli]

After some consideration, and in response to concerns raised by @waldemarhorwat at the plenary, I think we should drop roundingMode as a constructor or .convertTo() option, and instead always use round-ties-to-even.

This would match what the rest of ECMA-262 is doing, and avoid the problems caused by truncation. This would not prohibit the definition and use of rounding mode as a formatting option, either in the Intl.NumberFormat constructor options, or in Amount's .toLocaleString() options.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://tc39.github.io/proposal-amount/pr-preview/pr-90/
Built to branch gh-pages at 2026-04-23 15:01 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[sffc]

Rounding of numbers can be done in binary or in decimal.

The ECMA-402 rounding modes are designed for use in decimal rounding. They should always be available when rounding a decimal and should never be available when rounding a float.

[jessealama]

Rounding of numbers can be done in binary or in decimal.

The ECMA-402 rounding modes are designed for use in decimal rounding. They should always be available when rounding a decimal and should never be available when rounding a float.

Since we've agreed that .convertTo always results in an Amount whose underlying value is a Number (regardless of what type the original underlying value was), it makes sense to drop rounding options there.

[jessealama]

(I added a merge commit to resolve the conflict with main.)

[jessealama]

I think that we want to have NumberFormat format Amount objects. If that's right, couldn't Amount rounding be delegated to 402? In other words, since 402 already supports rounding, do we need Amount to independent support rounding, too?

[jessealama]

Since we've agreed that .convertTo always results in an Amount whose underlying value is a Number (regardless of what type the original underlying value was), it makes sense to drop rounding options there.

I need to correct my own comment. Looking at #86, I see that .convertTo produces String-backed Amounts. Does this reflect an up-to-date understanding? I thought that the thinking was that unit conversion, since it involves arithmetic, causes us to work with Numbers, with the result being a Number. Or do we want to work with Numbers, and then produce a String-backed Amount?

[eemeli]

My understanding of the prior consensus is that we want to do the conversion using Number values, but then always apply rounding to the result, getting us a String value.

I am, however, open to considering that a .convertTo() call with no rounding options would result in a Number-based Amount, while a call with rounding options would result ins a String-based Amount.

We may also want to reconsider whether the min/max versions of the significant/fraction digit options might make sense also for the constructor, but this is already getting quite a bit beyond the scope of this PR.

[eemeli]

On today's call we resolved to keep the roundingMode options.