Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121643
MIME-Version: 1.0
References: <CAFv4g+EqzB7whakuN-sr6YL2ih9xhHPzCsvTsEgJKMXBh9H9wQ@mail.gmail.com>
 <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk> <CAGBsUrfwRExOFZ8dRy0=D9wmKurkj4QBNPvOsmrw7Mh=rjX0mg@mail.gmail.com>
 <1A044D32-019A-4152-A3C0-3F393974AC3B@craigfrancis.co.uk> <CABigaAXMapTU_DKNq-Jz1Mo+NM01EVZjjaUG+9oa9bxxeScq3A@mail.gmail.com>
 <88815C70-1100-442A-AFCC-A420862669C3@craigfrancis.co.uk> <e90e7b26-021d-46d0-ae6b-87848bea9565@gmx.net>
 <6049A048-1B2B-4DD8-B2DD-05F7CFBB8EE6@craigfrancis.co.uk>
In-Reply-To: <6049A048-1B2B-4DD8-B2DD-05F7CFBB8EE6@craigfrancis.co.uk>
Date: Fri, 10 Nov 2023 14:34:49 +0100
Message-ID: <CAPzBOBPcw=HMYnhRm8Vf=N2KeQ5ngOwucaoaQrJSAf0ri-3Bsg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: Andreas Leathley <a.leathley@gmx.net>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Passing null to parameter
From: landers.robert@gmail.com (Robert Landers)

On Fri, Nov 10, 2023 at 1:33=E2=80=AFPM Craig Francis <craig@craigfrancis.c=
o.uk> wrote:
>
> On 10 Nov 2023, at 12:16, Andreas Leathley <a.leathley@gmx.net> wrote:
> > Also note that in your example $q could be an array (leading to a fatal=
 error in the code)from the request data, which is why checking types thoro=
ughly (not just coercing them with strval) can be helpful in avoiding unexp=
ected situations and deciding how to handle such situations, instead of yol=
o-ing it.
>
> Yep, and I completely agree, but I'm not focusing on my code, I'm looking=
 at the code the vast majority of developers write... and I do not want PHP=
 9 to be so difficult to use that people stay on PHP 8 forever.
>
> Craig
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Personally, I find the whole strict types + nullable thing really bad.

(string) null is "", which is hopefully pretty well known. But with
strict types, you may not even know you have a null value because
casting is used all over the code base. I constantly have to point out
this in code reviews and suggest this:

// val is an int|string|null
func((string) ($val ?? throw new LogicException("val should not be null")))=
;

which just feels dirty. At least in non-strict type mode, we would get
"null catching" for free (at the expense of deterministic coercion),
and is one reason we're actually considering to switch back to
non-strict types; a very simple coercion system for everything but
null.

So, really, I think it might be a good idea to rethink the whole type
system at some point. There isn't really any ideal solution atm for
handling nulls + strict types.


Robert Landers
Software Engineer
Utrecht NL