Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:121597 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39597 invoked from network); 6 Nov 2023 12:12:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Nov 2023 12:12:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 05BB7180087 for ; Mon, 6 Nov 2023 04:12:57 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,MIME_QP_LONG_LINE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS9370 160.16.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail.sakiot.com (mail.sakiot.com [160.16.227.216]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 6 Nov 2023 04:12:56 -0800 (PST) Received: from smtpclient.apple (107.64.239.49.rev.vmobile.jp [49.239.64.107]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.sakiot.com (Postfix) with ESMTPSA id 21E07401EE; Mon, 6 Nov 2023 21:12:53 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sakiot.com; s=default; t=1699272773; bh=Y8wUFrpHQXHUhp4UyUMMOIevqllHqlreCaQr7Z3qyW0=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=j8sFQGmudGHqloXNLBxTqu1us1cmZuWrB7dVBvg6GRnaKgmGEIGsXVZvPyeQ/gmyt lDdOgNqnndPzwEDn3inoqMfDRLAglmAt1hIrqfHF/IH/q1Mx6SqyqSooHVGBxMfY8/ B/rzQntW/ku1V5xR+l5D3o4wDcg+prdtTLPh8DyQ= Content-Type: multipart/alternative; boundary=Apple-Mail-17555B7C-D4CE-4A19-92D6-BAD748C9F0BA Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 6 Nov 2023 21:12:40 +0900 Message-ID: <095E59EE-173A-4114-AD3F-4B830CD2E295@sakiot.com> References: Cc: PHP internals In-Reply-To: To: Claude Pache X-Mailer: iPhone Mail (21A360) Subject: Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round() From: saki@sakiot.com (Saki Takamachi) --Apple-Mail-17555B7C-D4CE-4A19-92D6-BAD748C9F0BA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Claude, > Reading the RFC, it is unclear for me what are the benefits of the change,= and whether it is worth the subtle breaking of existing code that implicitl= y relies on the current behaviour. =E2=80=9CFP is just FP=E2=80=9D looks lik= e an ideal position, and one that has a counteragument given in the RFC that= introduced the current behaviour.=20 >=20 > We could live with any behaviour of round(), and they are arguments on bot= h sides. My issue at this point is not exactly what behaviour we have picked= , but whether changing between the two is sufficiently motivated. As for the motivation for the change, it's based on the idea that the curren= t `round()` behavior is some kind of bug. In other words, the behavior of HALF_UP `0.285` to become `0.29` is itself a= bug. To be honest, I'm completely neutral on this. I believe that this is a matte= r of will and what we want to do. As far as I know, Tim and Gina want change= on this issue. I don't want to ignore such opinions and move forward with i= mplementation, so I would like to hear a wider range of opinions. I have created this RFC in order to determine "our intention" once again. Regards. Saki= --Apple-Mail-17555B7C-D4CE-4A19-92D6-BAD748C9F0BA--