Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117699
Message-ID: <c2b2cf4c-f702-2685-82fa-aecabb3e6d97@telia.com>
Date: Sun, 8 May 2022 23:33:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-GB
To: Aleksander Machniak <alec@alec.pl>,
 php internals <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>
 <5598bad8-4e1a-7638-d3aa-36b02568d1a8@alec.pl>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <5598bad8-4e1a-7638-d3aa-36b02568d1a8@alec.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2022-05-08 kl. 08:52, skrev 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.
> 
It's not only ugly code ;) To make your program/application/library 8.1
compatible using that codepattern requires en effort, but brings close
to zero improvement, except being 8.1 compatible. So the net effect is
negative.

r//Björn L