Shane F. Carr

Based on additional discussion in the email thread, I would like to move forward with the recommendation in https://github.com/unicode-org/icu4x/issues/3284#issuecomment-2030731133, with the additional understanding that we may add support for locale-based...

Discuss with: - @younies - @eggrobin - @skius

- @eggrobin - "expand" came out of nowhere. - @sffc - (discusses history of how ECMA arrived at it) - @Manishearth - We could provide both "away_from_zero" and "expand" as...

A slate of names to consider in the future (suggested by @eggrobin): - `round_ceiling` - `round_flooring` - `round_expanding` - `round_truncating` - `round_half_ceiling` - ... - `rounded_ceiling` - ...

With the addition of @jedel1043's new RoundingIncrement functions, @markusicu noted that the matrix of these rounding functions is very large and unwieldy. I believe we now have 36 rounding functions,...

Seeking consensus on the following proposals for 2.0: ### Part 1 Remove the self-moving rounding functions in order to reduce API bloat. See previous post. Seeking consensus from: - [x]...

As part of this issue, we should also address the documentation feedback @markusicu left in the RoundingIncrement API Review here: https://docs.google.com/document/d/1gKZCaiTG2eeyxrIKUF2tf6PIsaPCIBaUVRXD-JDh6dI/edit#heading=h.7pm5mstzwo40

> On Alternative B, you could drop the `_to_mode` suffix/infix. My proposal is that `round` performs default half-even rounding, which means we need some other name for the function that...

> > My proposal is that `round` performs default half-even rounding > > This is consistent with Python, but I think it's more common to use half-expand rounding by default....

It is in FFI and therefore impacts 2.0