Hi, On 03.10.23 14:41, Tim Düsterhus wrote:
HiOn 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 peopleCorrect, 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.
I do understand and I agree that it's not optimal but the issue is the lack of good alternatives.
I only see three possible ways and all of them are suboptimal: 1. Don't trigger upcoming behavior change message (deprecation message) * impossible to opt-in new behavior in 8.4* This could lead to different application behavior overlook on upgrade to 9.0
2. trigger upcoming behavior change message without possibility to opt-in new behavior (as proposed)
* impossible to opt-in new behavior in 8.4 * either force old behavior or noise in logs 3. introduce new argument * possibility to opt-in new behavior in 8.4 * introducing a new argument which is already deprecated is just weird* forcing users to migrate twice (set argument in 8.4 and remove in 9.0 or 10.0)
* very long migration phase in case of removing argument in 10.0I think it would be great in this case to have a way of triggering an upcoming behavior change message even lower prio than a deprecation message but I don't see this being possible.
As far as I understand you are in favor of option 1. (considering it a bugfix) but how do you make sure this will not lead to different application behavior overlooked on upgrading? Also there is no way to opt-in new behavior.
Best regards Tim Düsterhus
Best, Marc
OpenPGP_0x3936ABF753BC88CE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
