Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117695
Message-ID: <5598bad8-4e1a-7638-d3aa-36b02568d1a8@alec.pl>
Date: Sun, 8 May 2022 08:52:37 +0200
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com>
 <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
 <CAMrTa2F10TkoR=iMQQELwJaWr9VcQ--sdnEZ38xNUpm-V9w1dg@mail.gmail.com>
In-Reply-To: <CAMrTa2F10TkoR=iMQQELwJaWr9VcQ--sdnEZ38xNUpm-V9w1dg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: alec@alec.pl (Aleksander Machniak)

On 07.05.2022 23:11, Jordan LeDoux wrote:
> What exactly would be the purpose of `?int` if this RFC was passed? To pass
> the value as null instead of 0? That's it?

Yes. No change here.

> What about `int|float`? Which one would it be coerced to?

What happens if you pass FALSE to such an argument? int(0). The same 
would happen with NULL.

> This pretty radically changes how typing itself
> would work in existing user programs. What I'm saying is that for such a
> radical BC break you need to provide some compelling justification.

If coercion is possible it should be done as it is done for 
bool/int/float/string. Inside the function you can still trust the 
variable type is as expected. The only difference is that it will not 
throw an error on NULL. Right now you can still use your function 
"incorrectly" and not get an error, e.g. if you pass FALSE to it (I 
understand NULL might be more common). And, if you use strict_types=1 
nothing changes for you.

I don't see this as a radical change. Definitely not more radical than 
making the code to throw errors where they were not thrown before (no 
matter how long the deprecation period was). So, imo the BC-break 
argument is not that strong in this case.

The consistency argument is also not that strong (but here probably more 
in favor of the change) because as it was mentioned already current 
behavior is consistent with some things and inconsistent with others.

The essential question is whether we want more of "weak-typing coercion" 
or not. More would mean that there's no breakage for existing code in 
PHP9 (essentially only 8.1 would be "broken" (because of the deprecation 
notice) so people could just skip it). No need for ugly code like "$var 
?? ''" everywhere is also a win.

Ok, this was my take, now I will shut up.

-- 
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com