Re: Passing null to parameter

From: Date: Fri, 10 Nov 2023 13:34:49 +0000
Subject: Re: Passing null to parameter
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-121643@lists.php.net to get a copy of this message
On Fri, Nov 10, 2023 at 1:33 PM Craig Francis <craig@craigfrancis.co.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 thoroughly (not just coercing them with > > strval) can be helpful in avoiding unexpected situations and deciding how to handle such situations, > > instead of yolo-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

« previous php.internals (#121643) next »