Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117676
Message-ID: <9109f8bb-2582-2578-f702-464f921590e5@telia.com>
Date: Fri, 6 May 2022 17:26:07 +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: Craig Francis <craig@craigfrancis.co.uk>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: NULL Coercion Consistency
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2022-04-08 kl. 19:34, skrev Craig Francis:
> Hi,
> 
> I've written a new draft RFC to address the NULL coercion problems:
> 
> https://wiki.php.net/rfc/null_coercion_consistency
> 
> This is due to the result of the Allow NULL quiz:
> 
> https://quiz.craigfrancis.co.uk/
> 
> 14 votes for Fatal Type Errors irrespective of `strict_types=1`;
> 13 votes for NULL coercion when not using `strict_types=1`;
> 8 votes to update some parameters to allow NULL;
> 
> I appreciate some want to force strict type checking on everyone, but I
> want to make sure we have this properly documented, with names, and
> explanations.
> 
> Breaking changes should be justified - if they aren't, they only
> make upgrading difficult and frustrating (bad for security).
> 
> Craig
> 
Hi,

Have been busy for a while and haven't followed all the details around
this RFC, but now back on track.

One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the
null coalescing operator like rtrim($string ?? '',...).

If one then has a legacy codebase that works flawlessly I would say that
this path is the preferred one since it requires a minimum of work. To
dig into your code base and address why the parameter ends up like null
is probably more cumbersome. OTOH, one doesn't reap the benefits of the
"Deprecate passing null to non-nullable arguments of internal functions"
RFC since it requires to much work.

One could argue that the "Deprecating passing null" RFC is nice, but has
a flaw when applied for existing code. Applying the null coalescing code
pattern is an easy way to make your code 8.1 compatible, but not sure if
it adds value to the application itself.

Now if this RFC is the best way to improve things if one think this is
something of an issue with the original RFC worth addressing I don't
know. But at least worth having a discussion about! The purist within
me sighs a little when applying the code pattern above...

r//Björn L