Re: NULL Coercion Consistency

On 26/05/2022 13:20, Craig Francis wrote:

First, the Docblock originally said this function did not accept NULL, but at runtime it accepted/coerced NULL to an empty string. This is exactly how htmlspecialchars() worked pre 8.1. Where developers using static analysis tools can choose to treat NULL as an invalid value, and those tools could report nullable variables as an error (via strict type checking).

The same events can be given a very different narrative: Originally, this function was not intended to accept null. The documentation clearly stated the accepted types, and any static analysis tool would reject any value not in that list. The author of the function chose to treat NULL as an invalid value. Because the list of valid types wasn't enforced at run-time, it was accidentally possible to pass null. Many developers who weren't using additional tooling came to rely on this bug, so as a compromise, the authors decided to change the documented behaviour of nulls. At no point did anybody look at the function and say "I can safely pass null to this, as long as I remember never to use static analysis tools". They accidentally passed null, and by luck got a useful result.

I also note that the commit message says "On PHP >= 8.1, an error is thrown if null is passed to htmlspecialchars." which is of course not true for native PHP, only if you make the highly dubious decision to promote deprecations to errors.

While I'd put the word "error" down as a typo, the intention is for 9.0 to throw a type error.

My point is that there is no action required on PHP 8.1. The commit message should have said, "On PHP >= 9.0, an error will be thrown if null is passed to htmlspecialchars."

And while user-defined functions are part of the conversation (for consistency reasons), I'm trying to find the benefits of breaking NULL coercion for internal functions (because, if there is an overall benefit, that Laravel Blade patch should be reverted).

This is a complete non sequitur. It's perfectly possible for different scenarios to support different decisions, and what Laravel decides that particular function should accept is based on their own assessment of the trade-offs. PHP is free to make an entirely different decision based on entirely different trade-offs. Meanwhile, the benefits have been explained repeatedly in this thread. You may not agree that they are worth the cost, and as I've repeatedly said, I have some sympathy for that. But please stop trying to take the conversation back to the very beginning by implying that you've asked a question and not received an answer. Regards, -- Rowan Tommins [IMSoP]