Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117517
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
In-Reply-To: <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
Date: Mon, 11 Apr 2022 19:22:16 +0100
Message-ID: <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c7fed305dc650609"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--000000000000c7fed305dc650609
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 11 Apr 2022 at 16:14, G. P. B. <george.banyard@gmail.com> wrote:

> But the implementation caused a Type Error when coercing NULL for everyon=
e
>> (even when not using *strict_types=3D1*), this seems more of an over-sig=
ht
>>
> is utterly wrong and was a conscious design choice based on the widely
> accepted view that nullable by default like Java is a mistake and defeats
> the purpose.
>


Bit hash... anyway, I've replaced that paragraph (it wasn't clear enough),
I just wanted to note how developers not using `strict_types=3D1` would see
it as an over-sight that coercion works for string/int/float/bool but not
null (despite what the documentation says), and how it's introduced a type
check (that they didn't ask for).

I assume you're using `strict_types=3D1`, and will be unaffected by this, s=
o
with all due respect, I'm not considering how you view or use NULL, nor do
I care what Java does, I'm simply focused on how most developers use NULL
in PHP.



"2. If the value can be coerced to the type requested by the hint without
> data loss and without creation of likely unintended data - allow"



Yep, as noted under the Documentation heading, and copying from the manual,
=E2=80=9CPHP will coerce values of the wrong type into the expected scalar =
type
declaration if possible=E2=80=9D... which it can, and does; for example, co=
ercion
to a string "null is always converted to an empty string".

https://www.php.net/manual/en/language.types.declarations.php#language.type=
s.declarations.strict

https://www.php.net/manual/en/language.types.string.php


[...] but this again brings us back to amending functions to have nullable
> arguments, not a blanket change.
>


As noted in the Introduction, second paragraph, unfortunately this won't
work (especially considering the ~335 parameters affected by this)... just
taking `htmlspecialchars()` as the most simple example, I asked a few
developers who use `strict_types=3D1`, and they did not want `$string` to
be a nullable argument, because NULL being passed to this argument suggests
there's a bug elsewhere in their code.

This view was also reflected in the quiz (the names are links to view their
answers):

https://quiz.craigfrancis.co.uk/



The breaking change was justified and explained, and voted unanimously in
> favour with 46 votes.
> The burden of justification is now on your end.
>


My whole RFC is the justification, from the lack of discussion of the
impact (where I will note that I am in favour of its intention of
consistency), the roughly 85% of scripts that do not use `strict_types=3D1`=
,
the almost certainly less than 33% developers who use static analysis, how
tools do not and will not fix this problem, how this goes against the
documentation, and all of the examples.

Keep in mind, if you're using `strict_types=3D1`, great, you're not affecte=
d
(I'm not either)... however, I work with quite a few developers, and it's
causing them a lot of problems, and their current approach is to either
disable the deprecation warnings, or to stay with 8.0, simply because they
do not have the time to make the changes... I will note that one team has
been trying to update their code base, it's about 6 months later, and they
still keep adding `strval()` to silence these deprecation warnings (yeah, I
know, not good, but it's the easy solution).



changing the type system into a broken and inconsistent way, and reversing
> a unanimously voted RFC needs strong justification.
>


I really appreciate your time to read my draft RFC, and I know there is no
way I can change your mind, but can you explain how would this be "broken
and inconsistent"?

Just take NULL to String coercion as an example, the documentation clearly
and simply says =E2=80=9Cnull is always converted to an empty string=E2=80=
=9D, this needs
to be updated to end with "... except when being passed to a function, in
which case NULL will result in a Type Error" (I think that's "broken and
inconsistent").

Craig

--000000000000c7fed305dc650609--