On 21 April 2022 15:40:42 BST, Christian Schneider <cschn...@cschneid.com> 
>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.


Rowan Tommins

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to