Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117791
MIME-Version: 1.0
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>
In-Reply-To: <73F563E2-7C31-4B5E-A6B9-AE1BD05ADD1C@craigfrancis.co.uk>
Date: Thu, 26 May 2022 09:01:25 -0500
Message-ID: <CANvqVdrmVOwKaMxsO6Awbr0KSpc=QjqNFwFivKphdT_KAZRcSg@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c3487605dfeaa046"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: michael.babker@gmail.com (Michael Babker)

--000000000000c3487605dfeaa046
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2022 at 7:21 AM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> That said, I would still like to know about the benefits of rejecting NUL=
L
> for `htmlspecialchars()`, in the context of that Laravel Blade patch;
> because, if it is beneficial (vs the BC break), they should revert that
> patch... shouldn't they?
>
No, they should not.  Laravel made an explicit choice to handle null values
in its escaping function for its templating framework.  That is their
choice to make. They should not be forced to implicitly handle null values
because the language decides to add implicit type coercion to user defined
functions (because consistency seems to be so important to some), and they
should not be forced to reject null values because underlying language
functions reject them as well.

Every implicit type coercion is a bug in hiding IMO.  If something doesn=E2=
=80=99t
explicitly support null, you shouldn=E2=80=99t have been passing null to it=
 in the
first place.  Relying on magic language behaviors to prevent type errors is
not a long term sustainable code pattern.  If a function, by explicit
design, can safely work with null values then that parameter should be
properly declared nullable.  If a function, by explicit design, does not
support null values then a type error is a hugely acceptable response.
Yes, that means that there is a lot of work involved for folks between now
and the release of PHP 9.0 to either refactor code to avoid type errors or
to get the language to expand the supported types in appropriate functions,
but IMO that effort from all parties is worth it in the long run to ensure
language consistency (I really don=E2=80=99t think userland PHP and
internal/extension PHP should have vastly different behaviors, and type
coercion support based on where a function is designed is one of those
holes that needs filled) and to ensure all APIs explicitly declare what
types of data they support.
--=20
- Michael Please pardon any errors, this message was sent from my iPhone.

--000000000000c3487605dfeaa046--