Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117679
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
In-Reply-To: <9109f8bb-2582-2578-f702-464f921590e5@telia.com>
Date: Sat, 7 May 2022 01:31:20 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F963B304-2653-4A70-AFFA-E2F5ED5090AD@craigfrancis.co.uk>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <9109f8bb-2582-2578-f702-464f921590e5@telia.com>
To: =?utf-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Subject: Re: NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

On 6 May 2022, at 16:26, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.com> =
wrote:
> Den 2022-04-08 kl. 19:34, skrev Craig Francis:
>> Hi,
>> I've written a new draft RFC to address the NULL coercion problems:
>> https://wiki.php.net/rfc/null_coercion_consistency
>> ...
>=20
> One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the
> null coalescing operator like rtrim($string ?? '',...).
>=20
> If one then has a legacy codebase that works flawlessly I would say =
that
> this path is the preferred one since it requires a minimum of work. To
> dig into your code base and address why the parameter ends up like =
null
> is probably more cumbersome. OTOH, one doesn't reap the benefits of =
the
> "Deprecate passing null to non-nullable arguments of internal =
functions"
> RFC since it requires to much work.
>=20
> One could argue that the "Deprecating passing null" RFC is nice, but =
has
> a flaw when applied for existing code. Applying the null coalescing =
code
> pattern is an easy way to make your code 8.1 compatible, but not sure =
if
> it adds value to the application itself.
>=20
> Now if this RFC is the best way to improve things if one think this is
> something of an issue with the original RFC worth addressing I don't
> know. But at least worth having a discussion about! The purist within
> me sighs a little when applying the code pattern above...


Thanks Bj=C3=B6rn,

My main concern is about backwards compatibility.

If this RFC fails, I think the only way for existing code to avoid the =
issue will be via an automated tool, but for it to do this safely, I =
agree with your suggestion, I think it will need to use null coalescing =
(or casting via `(string) $var` or `strval($var)`) at the variable =
sinks... but the idea of doing that to the ~335 parameters I've listed, =
is, well, ugly to say the least... but I'd much rather do that, instead =
of having projects stuck on 8.x (where they will inevitably stop =
receiving security patches).

I would like to know about the future benefits, and this is where my =
discussion with Rowan has been interesting (trying to work out the =
benefits vs costs)... but, tbh, I'm not really seeing a future benefit =
for breaking NULL coercion with internal functions (sorry). I do see =
benefits for consistency, and rejecting weird forms of type coercion =
(e.g. `htmlspecialchars(array())`), and I've tried to factor these into =
my RFC, but considering how NULL and an Empty String can often be seen =
as interchangeable (many developers giving no thought to the =
difference), I'm not sure how these fatal errors will help.

Craig