On 7 May 2022 12:54:45 CEST, Craig Francis <cr...@craigfrancis.co.uk> wrote: >I will note that my RFC does not change NULL coercion (why I quoted the >documentation), and I'm not against the other BC breaks where certain type >coercions are clearly problematic. > >It was 8.1 which introduced this specific BC problem (with ignorable >deprecation notices)... and while that change was to begin alignment with user >defined functions, it's the user defined functions that have been the oddity >(i.e. do not use NULL coercion, unlike other contexts, such as concatenation, >== comparisons, arithmetics, sprintf, print, echo, array keys). Personally I >think it should have been user defined functions that worked with the "old and >well known" coercion rules, and doing so would have reduced complexity (i.e. >working in the same way). ... >But my focus is on upgrading existing code, and this one is difficult to find >and update (e.g. the lack of tooling to help).
It is exactly user-defined functions that this RFC introduces breakage for. The behaviour to throw on null in user-defined functions exists since PHP 7.0, and is being relied on. Changing these now would introduce behaviour changes that are harder to find than new type errors. Using strict typing isn't an option either/would be just as much work as auditing the changes this would introduce. It may be that user-defined functions should have accepted null to begin with in your opinion, but that still makes it a breaking change now. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
