Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121299
MIME-Version: 1.0
References: <a973a0f1-6a1d-0219-2059-823d2db497d4@mabe.berlin>
In-Reply-To: <a973a0f1-6a1d-0219-2059-823d2db497d4@mabe.berlin>
Date: Fri, 13 Oct 2023 12:25:50 +0100
Message-ID: <CAEKnhAEhP9+adG02M3KnMLJjqqfSecs=0BR2mJSqTjGJ8AT2wg@mail.gmail.com>
To: Marc Bennewitz <marc@mabe.berlin>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000464720060797523a"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
From: bukka@php.net (Jakub Zelenka)

--000000000000464720060797523a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 26, 2023 at 11:39=E2=80=AFAM 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=3D1);

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

--000000000000464720060797523a--