On Mon, 7 Feb 2022 at 12:07, G. P. B. <george.bany...@gmail.com> wrote:
> The list of proposed functions is also excessive and just feels that any > function which raised a diagnostic during a test run on 8.1 was chugged > into it. > Not really, while I did create a throw-away script that used `get_defined_functions()` and `ReflectionFunction` to find all function arguments that accepted strings, and not `->allowsNull()`... I manually checked every single one, and I considered if passing NULL to that argument could represent a problem that warrants a Fatal Error for *everyone*. https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions.php This is why I have 2 other lists which I don't think justify any changes; e.g. it's almost certainly wrong to pass `NULL` to the `$characters` argument in `trim()`: https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-maybe.md https://github.com/craigfrancis/php-allow-null-rfc/blob/main/functions-other.md I'd argue that the length of the list represents the size of the problem (i.e. the amount of changes developers will need to make for PHP 9)... for example... - setcookie > - setrawcookie > > I really do not see why for the path and the domain should *ever* accept > NULL. Developers will often use NULL for argument defaults (remember, we didn't show that the default was an empty string in the documentation, just that it was an optional argument)... and considering the output for these two functions, I see it as pretty reasonable that NULL was used as a way to say "do not set the path attribute". setcookie('name', 'value', 0, '/', '', true); // set-cookie: a=a; path=/; secure setcookie('name', 'value', 0, '', '', true); // set-cookie: a=a; secure setcookie('name', 'value', 0, NULL, '', true); // set-cookie: a=a; secure So back to the same question as before, why should this NULL in the last line result in a Fatal Error for everyone who does this in PHP 9? Craig
