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-roundingI 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.
Where another set of functions would avoid the BC break it also would be 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.
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
Best, Marc
OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
