Re: Allowing NULL for some internal functions

On Thu, Dec 2, 2021 at 8:48 AM Craig Francis <craig@craigfrancis.co.uk> wrote: > On Fri, 26 Nov 2021 at 16:47, Sara Golemon <pollita@php.net> wrote: > > > I'm not saying send PRs to fix them all... Let's make PHP better, > > together. > > > > On a similar theme, trying to avoid too much work for developers upgrading > to later versions of PHP. > > Is there any value in me proposing an RFC to update *some* internal > functions so they can accept NULL? > > I see developers using their framework of choice for GET/POST/COOKIE/etc > values (where they receive NULL to represent unset values), or simply doing > $q = ($_GET['q'] ?? NULL), and other sources... where > they will now get > deprecation messages whenever they use functions like &Et�e1=8�Bk� > �htmlspecialchars(), > trim(), strpos(), > strtoupper(), strlen(). > > I'm not hard against this idea. The interpretation of null in these contexts as being equivalent to empty string isn't unreasonable. I guess the only objection I could have would be an academic one and I can't really defend that. So yeah, sure... why not? I would say that such applications should consider unifying their own types. $a = $_GET['q'] ?? ''; Is there a place in the application where empty string and null would have been distinct? i.e. Is a search for nothing different from not searching? -Sara