On 21 April 2022 15:40:42 BST, Christian Schneider <cschn...@cschneid.com> wrote: >You are leaving out option 3 (which is not part of the RFC but should still be >on the table IMHO): >3) Leave the behavior but change the parameter definition to nullable to match >the implementation.
Those weren't options, they were questions, or problem statements. Also, as he's repeatedly pointed out, Craig suggested making the parameters explicitly nullable, and received clear feedback that that wouldn't be popular. >> For instance, $search = ($_GET['q'] ?? ''); is both shorter and clearer than >> $search = ($_GET['q'] ?? NULL); > >Your version is lossy as you cannot distinguish between "empty query" and "no >query was submitted" any longer. The example passes the variable to htmlspecialchars, so this is exactly what will happen anyway - it returns an empty string for a null input. If you want to distinguish between null and empty string, you *must* avoid passing it to such a function, so the proposed error is a good thing. The whole argument in favour of coercing rests on code that *doesn't* need to distinguish between null and empty string. Note that as well as being shorter, this is more appropriate than using strval() or (string), which will accept other types as well as null. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
