On Thu, Dec 2, 2021 at 8:48 AM Craig Francis <cr...@craigfrancis.co.uk> wrote:
> On Fri, 26 Nov 2021 at 16:47, Sara Golemon <poll...@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 `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
