On 7 May 2022, at 18:16, Aleksander Machniak <a...@alec.pl> wrote: > On 07.05.2022 13:29, Mel Dafert wrote: >> 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. > > > Indeed. I suggest to add a note to "Backward Incompatible Changes" section of > the RFC. This changes the contract, but does not throw new errors in existing > code.
Thanks Aleksander, While I'm emailing Mel off-list about a more realistic example, I've added a simple example to demonstrate a BC break: https://wiki.php.net/rfc/null_coercion_consistency#backward_incompatible_changes <https://wiki.php.net/rfc/null_coercion_consistency#backward_incompatible_changes> ``` function my_function(string $my_string) { var_dump($my_string); } try { my_function('A'); // string(1) "A" my_function(1); // string(1) "1" my_function(1.2); // string(3) "1.2" my_function(true); // string(1) "1" my_function(false); // string(0) "" my_function(NULL); // Throw Type Error } catch (TypeError $e) { // Do something important? } ``` I believe the example Mel is looking at involves a function that should return an integer; and later, a second function should only be run when the returned value is `!== 0` (not `!= 0` or `> 0`, due to "style guides telling people to unconditionally prefer triple equal")... that's all working fine, but sometimes the first function can return NULL (I assume that indicates a problem), where it's useful to have the second function throw an exception when this happens (so no more processing happens, and it can be investigated). While I think there are better ways of handling this, I'll work with Mel to get this example into my RFC. Personally I think these are quite unusual, and don't match the size of the BC impact we face when internal functions (that have been accepting and coercing NULL since, well, forever) start throwing fatal type errors in 9.0. Craig
