number_format() changed undocumented behaviour since PHP 8.3.0

[langemeijer]

Description

https://3v4l.org/ELBNR

The following code:

<?php

echo number_format(3.1415, -1, ".", ",");

Resulted in this output since PHP 8.3.0:

0

But I expected this output instead:

3

No such change has been documented in https://www.php.net/manual/en/function.number-format.php

I understand -1 is not an expected value for $decimals, but if this change is intended I would have expected a E_WARNING or E_DEPRECATED before.

PHP Version

PHP 8.3.0

Operating System

No response

[langemeijer]

This seems intentional. #11487

Probably only a documentation issue then, but still an annoying little BC break in PHP 8.3. Also, please consider adding an E_DEPRECATED in 8.2.x future releases for this.

[iluuu1994]

This should indeed be mentioned in https://www.php.net/manual/en/migration83.incompatible.php.

[langemeijer]

I admire the speed of the documentation change in the migration BC-break list.

Please still consider adding an E_DEPRECATED in 8.2.x future releases for number_format() when $decimals < 0.

I understand not requiring the RFC procedure in case of a change like this. But if it means that the change get missed in documentation and deprecated in previous versions than that is a problem. Personally I think this change should have had an RFC and be voted for. I think https://wiki.php.net/rfc/number_format_negative_zero is much more of an edge-case than this one.

[iluuu1994]

@langemeijer I understand your frustration. We're trying to strike a balance of evolving the language, and keeping BC as much as possible. Please understand that deprecation and later implementation automatically becomes a multi-year endeavor. Furthermore, even with a deprecation, many users upgrade multiple PHP versions at once and as such may be missing the deprecation message.

Providing negative decimal values was previously dubious, because it was equivalent to 0. The risk was deemed small enough to give this range a new interpretation in the next minor version. Obviously, it's unfortunate it was missed in the upgrade notes.

[langemeijer]

I'm not frustrated. I understand not doing the RFC procedure in case of a change like this. I agree with the feature, and speed of changing PHP with such small improvements. I'm only coming back on it because you closed this github issue without acknowledgement of the suggestion I made. You could have NACK-ed it and that would be that.

But, I think you are dismissing the idea of adding an E_DEPRECATED too easily. It's a very simple change, costs near to nothing in production environments, and will be around until we EOL 8.2 in December 2025. This is two (ok 1.7) years that we can help our users identify they probably made a mistake in their code, and the behavior will change in 8.3.

From your perspective, the 8.3 train has already left the station and 8.2 is at it's end. For many users, upgrading their project's servers is a project that they will have to undertake, but somewhere before the end of next year. On any project that I upgrade to newer PHP versions, once projects stop spitting out deprecation errors, we know that the upgrade will go smooth mostly. Every E_DEPRECATED helps.