Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117687
Message-ID: <d98f7000-1ee9-0e43-b4e5-8bba19d20354@alec.pl>
Date: Sat, 7 May 2022 19:16:10 +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>
 <CADyq6sJ__0g1mrMtmSLjpJOz=KQhf+jHrQZH9O_Ch=qN0uzKgw@mail.gmail.com>
 <CE61E824-0106-46E3-8630-8A668E992FC0@craigfrancis.co.uk>
 <F915D2AA-BBE5-4B20-81F1-9260DFFA6377@dafert.at>
In-Reply-To: <F915D2AA-BBE5-4B20-81F1-9260DFFA6377@dafert.at>
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 13:29, Mel Dafert wrote:
> It is exactly user-defined functions that this RFC introduces breakage for.
> The behaviour to throw on null in user-defined functions exists since PHP
> 7.0, and is being relied on. Changing these now would introduce behaviour changes
> that are harder to find than new type errors.
> Using strict typing isn't an option either/would be just as much work as auditing
> the changes this would introduce.
> 
> It may be that user-defined functions should have accepted null to begin with in
> your opinion, but that still makes it a breaking change now.


Indeed. I suggest to add a note to "Backward Incompatible Changes" 
section of the RFC. This changes the contract, but does not throw new 
errors in existing code.


Now my 2 cents, reading docs and RFCs (I'm not the internals developer):

The https://wiki.php.net/rfc/scalar_type_hints_v5 says that NULL was 
excluded "in order to be consistent with our existing type declarations 
for classes, callables and arrays".

So, to me it sounds like the main reason was that NULL can't be cast to 
array/object/callable, not that it was expected to be treated as a new 
type in the future, nor more strictness was intended.

At the time excluding NULL made sense as it was a new feature anyway, 
and it didn't apply to internal functions, so it was fully sign-in 
feature. Although I must say that "it should be possible for existing 
userland libraries to add scalar type declarations without breaking 
compatibility" wasn't really true, because of NULL.

You could call the proposed NULL-to-scalar coercion in weak-type checks 
a new feature that makes 
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg 
obsolete/invalid, still, there are good reasons to do this. Imo, the BC 
break is much less problematic than the one we're trying to solve here.

-- 
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com