On 6 May 2022, at 16:26, Björn Larsson <bjorn.x.lars...@telia.com> wrote: > Den 2022-04-08 kl. 19:34, skrev Craig Francis: >> Hi, >> I've written a new draft RFC to address the NULL coercion problems: >> https://wiki.php.net/rfc/null_coercion_consistency >> ... > > One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the > null coalescing operator like rtrim($string ?? '',...). > > If one then has a legacy codebase that works flawlessly I would say that > this path is the preferred one since it requires a minimum of work. To > dig into your code base and address why the parameter ends up like null > is probably more cumbersome. OTOH, one doesn't reap the benefits of the > "Deprecate passing null to non-nullable arguments of internal functions" > RFC since it requires to much work. > > One could argue that the "Deprecating passing null" RFC is nice, but has > a flaw when applied for existing code. Applying the null coalescing code > pattern is an easy way to make your code 8.1 compatible, but not sure if > it adds value to the application itself. > > Now if this RFC is the best way to improve things if one think this is > something of an issue with the original RFC worth addressing I don't > know. But at least worth having a discussion about! The purist within > me sighs a little when applying the code pattern above...
Thanks Björn, My main concern is about backwards compatibility. If this RFC fails, I think the only way for existing code to avoid the issue will be via an automated tool, but for it to do this safely, I agree with your suggestion, I think it will need to use null coalescing (or casting via `(string) $var` or `strval($var)`) at the variable sinks... but the idea of doing that to the ~335 parameters I've listed, is, well, ugly to say the least... but I'd much rather do that, instead of having projects stuck on 8.x (where they will inevitably stop receiving security patches). I would like to know about the future benefits, and this is where my discussion with Rowan has been interesting (trying to work out the benefits vs costs)... but, tbh, I'm not really seeing a future benefit for breaking NULL coercion with internal functions (sorry). I do see benefits for consistency, and rejecting weird forms of type coercion (e.g. `htmlspecialchars(array())`), and I've tried to factor these into my RFC, but considering how NULL and an Empty String can often be seen as interchangeable (many developers giving no thought to the difference), I'm not sure how these fatal errors will help. Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
