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

From: Date: Fri, 06 Oct 2023 14:12:42 +0000
Subject: Re: [RFC] [Discussion] Rounding Integers as int
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-121249@lists.php.net to get a copy of this message
Hi George, On 05.10.23 14:12, G. P. B. wrote:
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.
Running a quick code search /round\([^\(]+\)\s===/ language:PHP on GitHub finds possible breakages based on strict comparison:
    // if width and height are ints
    $x = ( $height1 / $width1 ) * $width2;
    if ( round( $x ) === round( $height2 ) ) {
    // if number is int
    public static function isZero($number, $precission = 2)
    {
        return round($number, $precission) === 0.0;
    }
    // where ecb is int
    return $ecb && round(5000 / $ecb) === 2.0;
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


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