Re: NULL Coercion Consistency

On 27 May 2022, at 10:11, Rowan Tommins <rowan.collins@gmail.com> wrote: > 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'm really sorry, but I'm not sure what your point is... I was asking why passing NULL to htmlspecialchars() represents a problem, but we should just leave it, we're not getting anywhere. >>> 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." But deprecation messages do prompt developers to make changes (action is required). For those who do "no action", when they try upgrading to 9.0, they will have a bit of a problem (with no easy fix). >> 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. Sorry, but I'm not following... if there is a benefit/reason for PHP to reject NULL for htmlspecialchars(), and I'm just too stupid to see what it is, I would have assumed that benefit/reason would also apply to the HTML encoding function e() in Laravel. > 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. Sorry, I'm just not getting it, I have read and re-read all of your emails many times, and I'm clearly not clever enough to understand. Anyway, I've send a separate email about my RFC, because I cannot find a solution... I've tried my best, and I'm done. Craig