Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117537
Date: Sat, 16 Apr 2022 12:17:17 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
Message-ID: <42D0A480-F262-4F72-9C4D-887762A8D800@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: rowan.collins@gmail.com (Rowan Tommins)

On 8 April 2022 18:34:52 BST, Craig Francis <craig@craigfrancis=2Eco=2Euk> =
wrote:
>I've written a new draft RFC to address the NULL coercion problems:
>
>https://wiki=2Ephp=2Enet/rfc/null_coercion_consistency


I'm sympathetic to the general problem you're trying to solve, but I'm not=
 convinced by the argument that this is about consistency, because user def=
ined functions have been consistently rejecting null for non-nullable param=
eters since PHP 7=2E0, and even before that for arrays and objects=2E Consi=
stency is a good argument for small changes that eliminate unusual edge cas=
es, but I think far-reaching changes should be able to stand on their own m=
erits - regardless of whether it's consistent, do we want the language to w=
ork this way?

To me, the main defence of type coercion is that PHP operates in a world f=
ull of strings - URLs are strings, HTTP requests are strings, and a lot of =
API responses are strings - so making it easy to work with strings like '42=
' as numbers makes a lot of sense=2E It's not clear to me that this extends=
 to null=2E


I think a large part of the problem here is that null can mean many differ=
ent things in different contexts - "unknown", "not provided", "invalid inpu=
t", "default", "not applicable", etc=2E

These differences are subtle, but lead to different expectations of behavi=
our:

- Treat null as a specific case with its own meaning, distinct from any ot=
her valid value=2E This is what explicitly nullable parameters and union ty=
pes allow=2E
- Treat null the same as any other out of range value, and raise an error=
=2E This is what happens in user-defined functions in PHP, and in built-in =
functions expecting non-scalar arguments=2E Compare also out of range actio=
ns like division by zero=2E
- Treat null as a special state that propagates through expressions, becau=
se any operation with an unknown input has an unknown output=2E This is the=
 approach to null taken by SQL, and by IEEE floating point with NaN=2E It i=
s also the basis of the ?-> operator, and of things like Optional=2Emap in =
Swift=2E
- Treat null as a generic default value which can be filled in implicitly =
based on requirements=2E This is the interpretation currently taken by inte=
rnal functions for scalar arguments, and what you are proposing to make sta=
ndard=2E It is also, as you point out, the way PHP treats null in some othe=
r contexts, such as many operators=2E


Interestingly, one of your examples mentions filter_input, which takes the=
 "propagate" approach, and htmlspecialchars, which doesn't=2E It would ofte=
n be more useful to retain the information that a value is null than to hav=
e it silently converted to an empty string as a side-effect of some other o=
peration=2E=20

Perhaps it would be useful to have some function-call equivalent of the ?-=
> operator=2E I'm not sure what this would look like for normal function ca=
lls, but it would be easy to add if we had a pipe operator, e=2Eg=2E:

If this was equivalent to htmlspecialchars($foo)
$foo |> htmlspecialchars(=2E=2E=2E)

Then this could be equivalent to ($foo =3D=3D=3D null ? null : htmlspecial=
chars($foo))
$foo ?|> htmlspecialchars(=2E=2E=2E)


I'm not set against this RFC, but I'm not quite convinced by the case it m=
akes, and think there may still be other options to explore=2E

Regards,

--=20
Rowan Tommins
[IMSoP]