[RFC] [Discussion] Rounding Integers as int

> The deprecation would act as an information for upcoming behavior > change, not classical deprecation of future removal. If the new behavior > is what you want, than you don't need to change anything as a > deprecation message should not break anything. At the same time people

> I don't see a bug or broken behavior here as these functions were > processing floating point numbers since .... forever. > > https://3v4l.org/PrrmO >

> On Fri, Oct 13, 2023 at 1:26 PM Jakub Zelenka <bukka@php.net> wrote: >> On Tue, Sep 26, 2023 at 11:39 AM Marc Bennewitz <marc@mabe.berlin> wrote: >> >>> Hi internals >>> >>> I'd like to put a new RFC under discussion: >>> https://wiki.php.net/rfc/integer-rounding >>> >>> >> I would personally prefer a new function for rounding integers if anyone >> wants to round large integers. >> >> The things is that the current round behaviour is consistent with a way how >> floats to int conversion is done for strict types. >> >> <?php >> declare(strict_types=1); >> >> function test(float $a) { >> echo $a; >> } >> test(987654321098765432); >> >> >> So it won't really help that much if this function returns long for long in >> cases where the result is passed to another function expecting float. >> >> The main problem that I see with the current approach is that it changes >> return type for an edge case that most people are not impacted with. For >> example it is quite usual that people had a float value with 0 fraction >> which gets json encode to int. When they decode it and use round, the >> return type is suddenly int. Even though it's usually not a problem, there >> might be some code that expects float and maybe even assert that with >> is_float. Such code will break. >> >> On the other hand I see use some case for rounding large integers with >> negative precision. But for that to work I think it would be better to have >> a special function. >> >> If you really want to make such change to round, then I would be prefer >> targeting just 9.0 without any deprecation as I don't think the deprecation >> should be informational only and not fixable in the code. >> >> Cheers >> >> Jakub > Just to add some nuance, if you are going anywhere near the edges of > ints (e.g., custom encryption prototypes from papers), you generally > know that will happen -- it's math and pretty easy to verify. In those > cases, you likely will be using GMP or some other extension to handle > the large numbers. The point is, I highly doubt people are unknowingly > using round() with exceptionally large numbers. If they are doing so, > they probably know exactly what they are doing and already handle all > potential edge cases or they use an extension specifically for dealing > with large numbers.

> Hi Jakub, > > On 13.10.23 13:25, Jakub Zelenka wrote: > > On Tue, Sep 26, 2023 at 11:39 AM Marc Bennewitz <marc@mabe.berlin> > wrote: > > > >> Hi internals > >> > >> I'd like to put a new RFC under discussion: > >> https://wiki.php.net/rfc/integer-rounding > >> > >> > > I would personally prefer a new function for rounding integers if anyone > > wants to round large integers. > > > > The things is that the current round behaviour is consistent with a way > how > > floats to int conversion is done for strict types. > > > > <?php > > declare(strict_types=1); > > > > function test(float $a) { > > echo $a; > > } > > test(987654321098765432); > > > > > > So it won't really help that much if this function returns long for long > in > > cases where the result is passed to another function expecting float. > > > > The main problem that I see with the current approach is that it changes > > return type for an edge case that most people are not impacted with. For > > example it is quite usual that people had a float value with 0 fraction > > which gets json encode to int. When they decode it and use round, the > > return type is suddenly int. Even though it's usually not a problem, > there > > might be some code that expects float and maybe even assert that with > > is_float. Such code will break. > > > > On the other hand I see use some case for rounding large integers with > > negative precision. But for that to work I think it would be better to > have > > a special function. > > Your JSON example is a bit unrelated because if you care about your > types your should have used JSON_RESERVE_ZERO_FRACTION in the first > place else you should not care about int vs float at all. > >

> It's true that passing/returning int to/from a function expecting float > will cast but currently with these rounding functions it's a different > deal as they expect an `int|float` instead of just `float`. So it's not > cast on passing the argument but the functions itself are casting. > >

> against having PHP as a loosely typed languageputting the burden to > everyone caring. I already see hundreds of `is_int($v) ? round_int($v) : > round($v)` everywhere around. > >

> Hi internals, > > Just want to resent this note about the updated RFC as there where no > comments last time and I'm unsure if this was due to mailing list issues. > > I now have updated the RFC to allow to opt-in to new behavior on PHP 8.4 > and be able to opt-out to previous behavior in PHP 9.0 via new parameter > "force_float". > > Also the deprecation has been removed as nobody liked it. > > If no further comments arrive I'll like to start voting next week Friday. > > Best regards, > Marc