Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121231
MIME-Version: 1.0
References: <a973a0f1-6a1d-0219-2059-823d2db497d4@mabe.berlin>
 <CAFPFaMJd7nn7+p817K2U+W5LBOPVTNqoUvXAQHbw4uESFAogDg@mail.gmail.com> <cc93b17a-89d6-498d-9fe1-5e448449d137@mabe.berlin>
In-Reply-To: <cc93b17a-89d6-498d-9fe1-5e448449d137@mabe.berlin>
Date: Thu, 5 Oct 2023 13:12:42 +0100
Message-ID: <CAFPFaMLyu++Go4jsxQ69nj+iG5=sZdZYbwAJH0XQ9Z0kSFM3Nw@mail.gmail.com>
To: Marc Bennewitz <marc@mabe.berlin>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000026d5a20606f70bff"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
From: george.banyard@gmail.com ("G. P. B.")

--00000000000026d5a20606f70bff
Content-Type: text/plain; charset="UTF-8"

On Thu, 5 Oct 2023 at 07:40, Marc Bennewitz <marc@mabe.berlin> wrote:

> I don't see a bug or broken behavior here as these functions were
> processing floating point numbers since .... forever.
>
> https://3v4l.org/PrrmO
>
That's not my point, the point is about the function being broken for large
64bit integers, which your RFC is fixing.

I would also expect most people that actually use ceil/floor/round to dump
the return value of it into a property/value that is expected to be an int.
Which is also compatible for floats that fit in an int (and since 8.2 for
those that have a fractional part a warning is emitted).

I see no benefit in doing this weird approach instead of just changing the
behaviour.
Yes this is a theoretical BC break [1], but unless you can show me an
actual use case that breaks (and even then) I don't think the approach of
this RFC is good.

Best regards,

George P. Banyard

[1] And this is coming from me, who does love finding weird edge cases and
remove them from the language, just look at the 8.3 range() RFC

--00000000000026d5a20606f70bff--