Re: NULL Coercion Consistency
| From: | Rowan Tommins | Date: | Thu, 21 Apr 2022 16:40:00 +0000 |
| Subject: | Re: NULL Coercion Consistency | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-117562@lists.php.net to get a copy of this message | ||
On 21 April 2022 15:40:42 BST, Christian Schneider <cschneid@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]