Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117111
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> <CAFv4g+EGVfNP1bvwwKc5Pv2kiz3H2gBfAkzWM9TaDpDW1UOq+Q@mail.gmail.com>
In-Reply-To: <CAFv4g+EGVfNP1bvwwKc5Pv2kiz3H2gBfAkzWM9TaDpDW1UOq+Q@mail.gmail.com>
Date: Tue, 22 Feb 2022 04:58:35 +0200
Message-ID: <CAAwdEzDPEviPVkb-14-rAof+aoh=WeZcaZ0b4riYVfLC8k5ydA@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000068acb705d89287c5"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000068acb705d89287c5
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 21, 2022 at 5:32 PM Craig Francis <craig@craigfrancis.co.uk>
wrote:

> On Mon, 21 Feb 2022 at 09:04, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
> > That "inconsistency" had been introduced with PHP 7.0.0, i.e. right when
> > scalar type declarations have been introduced.  Passing a null to a
> > non-nullable parameter of a *userland* function throws a TypeError
> >
>
>
> Thanks Christoph, that's a good way of looking at it.
>
> Considering NULL has been passed to these internal function parameters for
> years, for a variety of reasons, and PHP has coerced it into an empty
> string, integer 0, float 0, or boolean false... I'm wondering if my RFC
> should focus on matching that expectation, so anyone not using
> `strict_types=1` does not need to make loads of hard-to-find/unnecessary
> edits; that way NULL would be treated the same as the other variable types
> (I appreciate arrays and objects don't get coerced, but I don't think
> anyone expects them to).
>

Yes, exactly that.
A few weeks ago when the issue was mentioned again I had to remember by
trying on 3v4l myself that using null for a string parameter wasn't an
automatically coerced case when strict_types = 0.

In my view, false would have the same problem for those internal functions.
Why should it be coerced to an empty string?
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg#proposal is
all about removing the automatic coercion that was happening for null in
the internal functions
Planning that in PHP 9 the type interpretation for internal function will
be done the same as for user defined functions. Consistency.

Right now, if a parameter type is defined as string in an user function, no
matter what strict_type is configured, it would still result in a TypeError
when passing null.
For internal functions, even if the parameter type is defined as string,
null would be passed and a coercion would happen.

As I mentioned, coercing false to int would be for me almost as bad as
coercing null to int.
But when types are not considered important I think it's worth pursuing
extending the coercion from null to the 4 other types where it's happening
right now:
- int as 0,
- float as 0.0,
- string as an empty string
- bool as false.

I don't like it and I have no good idea how that would work as it would be
a pretty big BC break.

Maybe it would be easier to change strict_types to default to 1 in PHP 9
along with adding the null coercion for null when strict_types is 0 rather
than inventing a new strict_types value like -1 that would allow null
coercion as well.
Starting with a notice in PHP 8.2 when the directive is not present might
be an interesting starting point. And no more warning for implicit coercion
when strict_types=0 directive is explicitly defined as it would not change
anymore in PHP 9.

Regards,
Alex

--00000000000068acb705d89287c5--