Hi Christoph,
> Hi!
>
>> On 12.07.2024 at 17:26, Claude Pache wrote:
>>
>>>> Le 12 juil. 2024 à 13:24, Christoph M. Becker <[email protected]> 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