Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121301
MIME-Version: 1.0
References: <a973a0f1-6a1d-0219-2059-823d2db497d4@mabe.berlin> <CAEKnhAEhP9+adG02M3KnMLJjqqfSecs=0BR2mJSqTjGJ8AT2wg@mail.gmail.com>
In-Reply-To: <CAEKnhAEhP9+adG02M3KnMLJjqqfSecs=0BR2mJSqTjGJ8AT2wg@mail.gmail.com>
Date: Fri, 13 Oct 2023 13:44:08 +0200
Message-ID: <CAPzBOBOd7wq8VKPUG_q+O8kKNF9Oa-23b8KY3dxEEYcFq+Ktcw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
From: landers.robert@gmail.com (Robert Landers)

On Fri, Oct 13, 2023 at 1:26=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote=
:
>
> 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 h=
ow
> 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, ther=
e
> 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 ha=
ve
> 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 deprecati=
on
> 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.