Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117179
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>
 <0b5bc29d-3814-0e1d-b94a-47790019c778@gmx.de> <5463E9FF-309D-4CFA-B709-81498B934059@cschneid.com>
In-Reply-To: <5463E9FF-309D-4CFA-B709-81498B934059@cschneid.com>
Date: Tue, 1 Mar 2022 14:12:35 +0000
Message-ID: <CAGBsUrf87kq5_kUXx5Z7dqaDBiebd=WyacQ0LrkHa-W6f8KmGQ@mail.gmail.com>
To: php internals <internals@lists.php.net>, Craig Francis <craig@craigfrancis.co.uk>
Content-Type: multipart/alternative; boundary="000000000000488e2405d928c280"
Subject: Re: [PHP-DEV] Allowing NULL for some internal functions
From: tekiela246@gmail.com (Kamil Tekiela)

--000000000000488e2405d928c280
Content-Type: text/plain; charset="UTF-8"

Hi Craig,

> No, there is an inconsistency which leads to a backwards compatibility
issue, and I'm trying to fix it.

Which inconsistency exactly do you have in mind?

The discussion is about passing arguments to functions. We are not
discussing type juggling or type casting. To clarify the whole thing let's
list out the key points:

- PHP has a concept of scalar types consisting of these four types: string,
int, float, bool
- PHP has type juggling that converts the value to the type required by the
context in which it is used. The behaviour is defined for scalar types, but
often undefined for other types (see juggling to array)
- PHP lets users cast values to a specified type. There are 7 (+1)
available casts in PHP (disregarding aliases). Casting to scalar types from
scalar types is defined. Casting to scalar from other types is partially
defined and causes undefined behaviour in some cases. Warnings are
generated in certain situations (e.g. array to string) and fatal errors
when the cast cannot be performed at all.
- PHP has a special type called NULL with a single value NULL. It's not a
scalar and it's not a stand-alone type. Casting to NULL is not possible.
For all intents and purposes, NULL value represents a variable with no
value. For this reason, converting to other types generally does not cause
any notices, warnings or errors. However, using NULL might generate
warnings or errors depending on an operation. e.g. `null[0]`,
`null->scalar` or `[...null]`
- PHP has a concept of strict typing. It applies only to scalar parameters.
By default, PHP will coerce values of the wrong type into the expected
scalar type declaration if possible. NULL being a non-scalar value doesn't
coerce in non-strict mode. Neither does array, object or resource. See
https://3v4l.org/WZdQC

The only inconsistency is that PHP's internal functions silently accepted
NULL values for non-nullable parameters. This will be addressed in PHP 9.0.

Changing the signatures of some functions might be reasonable but, as few
others have said, it's not the solution we want to see because it feels
like a hack. As I have also pointed out off-list, in many cases making the
parameter type nullable would not make any sense as passing null to certain
functions is a clear bug. It would also have an impact on strict typing!

We could also reclassify NULL as a scalar type but that would be a
fundamental language change. It would likely be a bigger BC change than
fixing the current inconsistency.

By the way, your statement that "Coercion works for string/int/float/bool,
*and* NULL." is invalid. Coercion is defined only for scalar types as I
have explained above. Type juggling for most types from NULL is defined,
but that is not what we are discussing.

Regards,
Kamil

--000000000000488e2405d928c280--