Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117217
Message-ID: <96d2babf-63d5-9fdb-8b95-a117247a9d21@gmx.net>
Date: Wed, 2 Mar 2022 16:21:09 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Content-Language: en-US
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: internals@lists.php.net
References: <CAFv4g+Efz-V5V1uUedXpusNw6z-on=TT3kdWgC66SptSd8kB4g@mail.gmail.com>
 <CAFv4g+GDsq=w7qtSOVptEBiTTDZk2aeFCVGThVBR=0-xk=0oAA@mail.gmail.com>
 <983552d8-11f1-b5bc-fb82-148347982fda@gmx.de>
 <5494eaa7-2fa6-8364-9683-a2c8c9789d81@gmail.com>
 <CAC5V6gjianVuPo654_-mETYxsu0-eSo++Ez1yy81MNEcfwFq1Q@mail.gmail.com>
 <69642616-72b7-44fe-97a7-27ae03bc8fce@www.fastmail.com>
 <CAFv4g+F0HOgCgeUyiG06qhxQnWbVCN2aaP=a2CJT9tkbMP7kLg@mail.gmail.com>
 <7fbed755-42e2-d023-285f-39863a97f297@gmx.de>
 <3665C848-B4C3-4528-AEFA-02C868748AA8@cschneid.com>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de>
 <CAFv4g+HPm+edmgnPAGwBk=4EJxj2can--iWfgtMasrYHk6pLww@mail.gmail.com>
 <4bff3f23-a3ec-4416-f44e-1f4f5d7e0caa@gmail.com>
 <CAFv4g+E159xoR4hxtsay-FamCSrJN+DmodvjzYGHcd1pQFsX+Q@mail.gmail.com>
 <c51f0919-82a0-dffd-47f2-f63f144feb5f@gmx.net>
 <CCA1B582-AE5E-4FC1-8452-5E261F046093@craigfrancis.co.uk>
In-Reply-To: <CCA1B582-AE5E-4FC1-8452-5E261F046093@craigfrancis.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: a.leathley@gmx.net (Andreas Leathley)

On 02.03.22 16:00, Craig Francis wrote:
> I'll note that converting from NULL is used all the time, and is well
> defined:
>
>> https://www.php.net/manual/en/language.types.string.php
>> "null is always converted to an empty string."
>>
>> https://www.php.net/manual/en/language.types.integer.php
>> "null is always converted to zero (0)."
>>
>> https://www.php.net/manual/en/language.types.float.php
>> "For values of other types, the conversion is performed by converting
>> the value to int first and then to float"
>>
>> https://www.php.net/manual/en/language.types.boolean.php
>> "When converting to bool, the following values are considered false
>> [...] the special type NULL"
>
This is the behavior for explicit type casting (strval) and the implicit
casting when using a variable in a string context, like echo or print.
This is basically just a base necessity - for example an array is
converted to "Array". All information about the array is lost, except
that the string is now called "Array". So would you say something like
htmlentities should also accept array values and automatically convert
it to the string "Array"? It is used all the time with echo and print,
and it is well defined, yet it is still not a good idea. For strval and
for echo it makes sense to convert an array to "Array" (barely, to end
up with a somewhat useable string), but for parameter types it does not
make sense. The same goes, in my opinion, for null.

> It really depends on your code base... Laravel,=C2=A0Symfony,=C2=A0CakeP=
HP,
> CodeIgniter (the frameworks I'm familiar with) all return NULL for
> missing GET/POST/COOKIE values, and that is a useful feature... but
> when the developer naively passes that to any one of those listed
> parameters, you will get a deprecation message in 8.1, and a Type
> Error in the future... and finding all of these is incredibly hard.

These frameworks change their types and signatures quite often - much
more than PHP ever does. One Symfony project of mine that is now 7 years
old has had crazy changes, both in types, signatures, directory
structure, etc., yet people adapted and the changes were for the better.
Compared to the changes produced by frameworks this deprecation about
string values and null seems much smaller to me. And I do think it is
important that coercions in the language become less frequent rather
than more frequent, also because the language does have a certain "role
model" effect. From 7.0 until 8.1 it was a legacy effect that converted
null to an empty string, and only for internal functions, but with your
proposal it would be an intentional decision to start treating null and
scalar types more interchangeably.