Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117177
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>
 <CAFv4g+F85=Bfw2GCo638AZyBomcG-0bHweYLffqhHFsHznNYtA@mail.gmail.com> <621dec08.1c69fb81.23ab4.ce84SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <621dec08.1c69fb81.23ab4.ce84SMTPIN_ADDED_MISSING@mx.google.com>
Date: Tue, 1 Mar 2022 12:55:22 +0000
Message-ID: <CAFv4g+G=8L9K31SQrofn6YN7TQ4eLZ+QGnYZxi9duHAOLJFOjA@mail.gmail.com>
To: Mark Randall <marandall@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000578bf205d927ae57"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000578bf205d927ae57
Content-Type: text/plain; charset="UTF-8"

On Tue, 1 Mar 2022 at 09:48, Mark Randall <marandall@php.net> wrote:

> You see a problem, but rather than trying to fix the underlying cause,
> you're proposing making changes at other layers to accommodate the side
> effects of the original problem.
>
> That is practically the definition of a hack.
>


No, there is an inconsistency which leads to a backwards compatibility
issue, and I'm trying to fix it.

I'm sorry I'm clearly no good at explaining this... maybe I should try
bullet points...

I am not trying undo the intent of the original RFC (constancy is good).

PHP has type coercion when not using `strict_types=1`; this is a feature,
one you might not like, but many do.

Coercion works for string/int/float/bool, *and* NULL.

It even has it's own clear paragraphs explaining this in the manual:

"null is always converted to an empty string."
"null is always converted to zero (0)."
"the following values are considered false ... NULL"

Not only does this happen with function parameters, but also non-strict
comparison operators, e.g. `($nullable == '')` is true for NULL.

It was only user-defined function parameters with a specified type
(introduced in PHP 7.0) that broke that consistency, and only for NULL,
because the other types continued to be coerced, it was just NULL that was
the oddity.

This is important because NULL is used a lot, as both a distinct value, and
as a convention as the default for parameters (ref setcookie).

And internal functions have always accepted NULL.

As of 8.1, the inconstancy between user-defined vs internal functions was
addressed (good, I dislike consistencies), but the details were barely
discussed (one message, from Craig Duncan):

https://externals.io/message/112327

I'm trying to avoid an upgrade problem for PHP 9.0.

I want to keeping the strict checks in place for those who
use `strict_types=1` (so Mark, you would not be affected by this, as I
assume you use `strict_types=1` for everything).

And note the complete lack of tools to fix this issue, and how many
instances would need to be changed.

Unless you're planning to force `strict_types=1` on everyone (Type Errors
for all, remove all type coercion), this inconstancy does not make any
sense.

Craig

--000000000000578bf205d927ae57--