Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117219
MIME-Version: 1.0
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>
 <96d2babf-63d5-9fdb-8b95-a117247a9d21@gmx.net>
In-Reply-To: <96d2babf-63d5-9fdb-8b95-a117247a9d21@gmx.net>
Date: Wed, 2 Mar 2022 16:24:53 +0000
Message-ID: <CAFv4g+Fo4Lm_0TiPTvs3k0cc2NJ3AndgKuprjFON_1XPNky6rA@mail.gmail.com>
To: Andreas Leathley <a.leathley@gmx.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005d227f05d93eb916"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--0000000000005d227f05d93eb916
Content-Type: text/plain; charset="UTF-8"

On Wed, 2 Mar 2022 at 15:21, Andreas Leathley <a.leathley@gmx.net> wrote:

> 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.
>


But that's what the RFC is about.

Although you do raise a good point, why does `print(NULL)` not complain?

Think about htmlspecialchars(1), that integer is going to be cast to the
string '1', in exactly the same way that NULL is cast to the string ''.


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"?



Oddly, I'm fine with `htmlentities(array())` being rejected, because it has
always been rejected... and, arrays/objects cannot be easily coerced to a
simple value (null can be, and is).

My focus is about not needlessly breaking code that works, I want everyone
to upgrade to PHP 9... you will notice I'm not complaining about the fairly
easy to implement `#[ReturnTypeWillChange]`, the change for
`mysqli_report()`, or the change I made for `htmlspecialchars()` to ensure
single quotes are encoded by default... but tracing very variable from
source to sink, that is *hard*.


> It really depends on your code base... Laravel, Symfony, CakePHP,
> > 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



Yes, but, as noted, returning NULL for a missing value is useful... I
highly doubt they will change these function signatures so the default is
an empty string, and make the return value always a string.


Compared to the changes produced by frameworks this deprecation about
> string values and null seems much smaller to me.



It's a small problem today, because it's a new deprecation (note how
WordPress is just telling people to ignore it)... the problem comes when it
becomes a Fatal Error.


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.
>


I am not making it more frequent, it's how it has ways worked (with the
oddity of user defined functions that specified parameter types); if you
don't like coercion, that's fine and good, but you should be using
`strict_types`... if PHP isn't going to support any coercion, then also
fine, but deprecate it all (and accept the consequences).

Craig

--0000000000005d227f05d93eb916--