Re: [RFC] [Discussion] Rounding Integers as int

From: Date: Sat, 14 Oct 2023 00:21:17 +0000
Subject: Re: [RFC] [Discussion] Rounding Integers as int
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-121304@lists.php.net to get a copy of this message
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. 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

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0x3936ABF753BC88CE.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc
« previous php.internals (#121304) next »