Hi On 9/30/23 08:26, Marc Bennewitz wrote:
The deprecation would act as an information for upcoming behavior change, not classical deprecation of future removal. If the new behavior is what you want, than you don't need to change anything as a deprecation message should not break anything. At the same time people
Correct, the deprecation message itself would not break anything. However when the new behavior is the behavior I desire, it would:
1. Cause noise in my logs, because the deprecation would continue to be emitted until the behavioral change is finally implemented. 2. Be confusing when working in preparing my application for future PHP versions by handling all deprecations.
The only solutions would be either adding an '@' in front of every call to round, ceil, floor (which might suppress additional errors I *do* care about) or ignoring this specific deprecation within the error handler of the application after verifying that I checked all locations for correctness. There is no way for me to reliably mark only this specific deprecation as acknowledged / handled for a specific place within my code.
This also extends to library developers who are already under pressure by users to make their libraries deprecation free on or before the release of a new PHP version. As the library doesn't control the error handler, they can't just ignore this specific deprecation for their library, without casting the input to float, despite being happy with the new behavior that will arrive in PHP 9.
In other words, this deprecation is not really actionable to me as a developer, because I can't migrate to the new behavior on my own pace.
Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
