Hi, > On Sunday, 2 June 2024 at 22:26, Jorg Sowa <jorg.s...@gmail.com> wrote: >> > by *removing* the newly introduced constant and instead exposing the >> > functionality *only* via the new Enum. >> >> It brings inconsistency that some modes are accessible by ints and enums and >> others only by enums. If there is no deprecation plan yet I am not sure this >> is the right approach. > > We cannot formally deprecate the constants in the same version as introducing > the enums as there would be no transition period. > We can however soft deprecate the usage of the constants in the documentation > by recommending to use the enumeration instead. > > However, I don't see _any_ point in having both constants and enum cases for > the new modes as there is no incentive what so ever to use the enum. > It is *by design* to have an inconsistency, you want the new feature, use the > new and better way. > > Let's imagine we do introduce those new constants alongside the enum, from a > user PoV there is no clear reason why one should use constants above enums or > enums above constants, except if you care about type safety. > Now, let's fast forward in this imaginary world and we decide to formally > deprecate the constants and tell people to use the enum. > For every single user that decided to use the constants, especially for the > new rounding modes, they now need to go and fix their code because we didn't > clearly incentivise people to use, what I deem, to be the recommended way > forward. > > Moreover, this equivalence will be an argument _against_ deprecating the > constants. > And finally, if we decide to add actual support for half up/down rounding, > there is no way to establish an equivalence with a sanely named constant > because the name is already taken for an incorrect mode. > > So once again, if this RFC does not remove the constants for the new rounding > mode I see less of a point, because it is "just" improving the naming (which > is really needs considering how bonkers wrong it currently is). > This RFC *must* be passed for 8.4 to ammend your RFC, because I frankly don't > want to be doing clean-up on yet another bad decision the project did that > will haunt us for decades if the current state gets released. > > Best regards, > > Gina P. Banyard
To summarize the discussion so far, it seems that there is a lot of support for the concept of this RFC itself. The current points of discussion are the following two points: 1. Whether or not to provide the new rounding modes added in 8.4 as constants. 2. Naming of modes equivalent to floor/ceiling Regarding 1, personally, I support Gina's opinion of only providing the new rounding modes as an Enum. This can be interpreted as changing the rounding mode to Enum, with the existing constants being kept simply for backward compatibility. Regarding 2, I like the PositiveInfinity/NegativeInfinity expression. As far as I know, there doesn't seem to be a clear distinction between these and ceil/floor. There are several other expressions, such as upward and plus inf, but they all seem to refer to the same concept. Regards, Saki
