[RFC] [Discussion] [VOTE] Rounding Integers as int

> Hey Marc, > > On 18.3.2024 08:53:01, Marc Bennewitz wrote: >> Hi Bob, >> >> On 17.03.24 14:59, Bob Weinand wrote: >>> On 17.3.2024 13:23:04, Marc Bennewitz wrote: >>>> Hello internals, >>>> >>>> I have opened the vote for the "Rounding Integers as int" RFC: >>>> https://wiki.php.net/rfc/integer-rounding >>>> >>>> Do to Easter weekend the vote will run for two weeks and two days >>>> until Tue the 2nd of April 2024. >>>> >>>> Best regards, >>>> >>>> Marc Bennewitz >>> >>> Hey Marc, >>> >>> I've voted no; it should be just changed without any force_float >>> parameter. Just always return int when possible (and the input was >>> int). >>> If users wish to have the old behaviour, they should just explicitly >>> cast via (float). >>> >>> The effective BC break of that would be quite small if some things >>> which return float today now would return int. I cannot imagine many >>> cases where this would actually be unwanted. And as said, explicit >>> (float) casts are always possible. >>> >>> I also dislike force_float, as it cannot just be added to a function >>> in any code which shall be backwards compatible to 8.3 and older. It >>> would just emit Uncaught Error: Unknown named parameter $force_float. >> >> Changing the return type from float to int is a non trivial quite >> hard to find behavior change. >> >> Imaging code like this: >> >> $x = 800; >> $y = 800; >> round($x/$y) === 1.0; >> >> This will return false instead of true especially because we teach >> users to use strict comparison. >> Such behavior change should be done in a major version. > > I see, here we disagree: > - Strict comparison should be avoided when working with numbers. > Strict comparisons are generally for strings and booleans. > - There's no reason to artificially wait years here.

> >> With the additional parameter it's possible to opt-in into the new >> behavior already in 8.4 while in PHP 9.0 the default behavior will >> change but previously opted in code does not need to get touched again. >> >> Just changing the behavior means waiting for PHP 9.0 without a way to >> opt-in in 8.4 already. If you are not interested in opting in in 8.4 >> already you can just ignore the additional argument as this will be >> the default in 9.0. > I'm not interested in having an additional parameter I have to carry > forward for quite some years. >> To mimic the previous behavior in a fully BC way it's as simple as >> explicitly casting the value to float. > > I would rather have preferred to see a static analysis solution how > often round()ed results are compared strictly, assess the actual BC > impact and possibly encourage tools like Rector to recognize such > patterns.