On 27 May 2022, at 10:11, Rowan Tommins <rowan.coll...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
