On 16.01.2025 at 02:49, Craig Francis wrote: > On Fri, 3 Jan 2025 at 16:03, Kamil Tekiela <tekiela...@gmail.com> wrote: > >> It is a step towards making the user-defined functions and built-in >> functions consistent with each other. > > Just to note, it could have been "consistent" if NULL coercion was > supported for user-defined functions (when not using strict types), in the > same way that user defined functions coerce the other types:
null is not a *scalar* type, and it shouldn't be treated as such. The fact that it still silently coerced when used as operand is something to tackle in the future, but not an argument to revert a long-standing deprecation. And of course, it's up to everyone to just brush null returns under the carpet one way or the other, but at least for functions which are not documented to return null (like htmlspecialchars()), it might be better to look for a cleaner solution, since otherwise you rely on undefined behavior. https://www.php.net/manual/en/functions.internal.php: | If the parameters given to a function are not what it expects, such as | passing an array where a string is expected, the return value of the | function is undefined. In this case it will likely return null but | this is just a convention, and cannot be relied upon. As of PHP 8.0.0, | a TypeError exception is supposed to be thrown in this case. And wrt other potential null values like for superglobals and database results, you also may be better off to handle these differently than empty strings. Note that I'm generally in the coercive type camp. Christoph
