Hi Christoph, > Hi! > >> On 12.07.2024 at 17:26, Claude Pache wrote: >> >>>> Le 12 juil. 2024 à 13:24, Christoph M. Becker <cmbecke...@gmx.de> a écrit : >>> >>> […] At the very least we should be sure that we want to keep >>> this change, and document it well, to avoid discussions in every filed >>> ticket. >>> >>> […] Thus, I think the change >>> should better be reverted, and if at all, postponed to PHP 9, since I >>> neither regard this change as bug fix nor as a feature. >> >> See [1] and [2], which motivated the change. > > Ah, thank you! I probably should have checked this more thouroughly; > now even I can see that there was a *bug*, so it is okay for me to stick > with the fix (thank you, Saki!), but maybe UPGRADING should clarify the > issue a bit. Currently, it states: > > | The maximum precision that can be handled by round() has been extended > | by one digit. > > While that is technically correct, probably few readers understand the > implications. > >> I expect that `round($anything) == (int) round($anything)` for any float >> between PHP_INT_MIN and PHP_INT_MAX, and I think that the change fixed that . > > It seems to me that this is a reasonable expectation. > >> Therefore, I am for keeping the change, and ensuring that there are test >> cases for 4503599627370495.5 (the largest float with fractional part). > > Makes sense (unless there is already such a test, of course). > >> [1]: https://github.com/php/php-src/issues/12143#issuecomment-1713465981 >> [2]: https://3v4l.org/3Q7BC > > Cheers, > Christoph
If this can be considered a bug fix, then I'm in favor of keeping it as is. (I wasn't sure if this should be considered a feature addition.) I will update UPGRADING with concrete examples. Regards, Saki
