Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116991
MIME-Version: 1.0
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+HvM5CPw6DNdsipYmZEb3zjWY2_Use4O+yfxAPBedzFUw@mail.gmail.com> <6200d9f4.1c69fb81.1d3f2.8b60SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <6200d9f4.1c69fb81.1d3f2.8b60SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 7 Feb 2022 12:05:00 +0000
Message-ID: <CAFv4g+H---mMk1kGDcHNPm3sqKiQ-DmMfOZAwt+Z=6X2LRB-7A@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000bd06fe05d76c6945"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000bd06fe05d76c6945
Content-Type: text/plain; charset="UTF-8"

On Mon, 7 Feb 2022 at 08:36, Mark Randall <marandall@php.net> wrote:

> I understand your motivations in proposing them, but to my mind it goes
> against the direction that PHP is developing, which I think is the right
> one, where errors and likely errors result in stopping execution rather
> than allowing it continue
>


Hi Mark,

Thanks for responding.

I'm not completely against this approach in general, but I'm trying to find
the right balance.

Back to my example; most frameworks return `NULL` when a user value is not
provided via GET/POST/COOKIE (this is a useful feature), and many
developers simply pass that nullable string through to functions like
htmlspecialchars(), urlencode(), etc... I do not understand why this is an
error so bad that it must result in a Fatal Error for everyone using PHP 9.

As noted before, I can see how NULL might represent a problem in projects
using `strict_types`, but I'm not proposing we change anything for them
(also much more likely to be using static analysis).

And specifically with NULL, strings in C are a "one-dimensional array of
characters terminated by a null character", so you could say that NULL is
very similar to an empty string - maybe that helps address the "pretend its
a string" objection?

Craig

--000000000000bd06fe05d76c6945--