Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117810
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
In-Reply-To: <24d35dc8-bd1d-3d90-99ac-ebdcc3b2a9e4@gmail.com>
Date: Sat, 28 May 2022 03:35:59 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <B835482D-FB65-4022-BE5F-2E4E3E72B360@craigfrancis.co.uk>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <1755E8B5-229B-47B2-BBAF-B5E014F5473D@craigfrancis.co.uk>
 <1180af01-080f-ee0a-3159-74bf7e0a8aea@gmail.com>
 <73F563E2-7C31-4B5E-A6B9-AE1BD05ADD1C@craigfrancis.co.uk>
 <24d35dc8-bd1d-3d90-99ac-ebdcc3b2a9e4@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

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).
>=20
>=20
> The same events can be given a very different narrative:
>=20
> 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.
>=20
> 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.
>=20
> 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 >=3D 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.
>=20
>=20
> My point is that there is no action required on PHP 8.1. The commit =
message should have said, "On PHP >=3D 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).
>=20
>=20
> 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