Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117555
Message-ID: <e63f5817-78bf-3490-202d-23022d81dc8e@gmx.net>
Date: Wed, 20 Apr 2022 21:02:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAFPFaML-dia9d7qhpqsVjaQ1vruF+eODXYtieow8BhZ69HL4YQ@mail.gmail.com>
 <CAFv4g+GQbFVtNvBQrrCYJpNEw-wpzd1QqTFpyyppFQjuMs8dSg@mail.gmail.com>
 <eed7bf5f-572f-11a4-51cd-542737cdacef@gmx.net>
 <CAFv4g+HOMThq1DKXFRA+_qGT6bw-fqzAvbwUADL-o-g4pwO6oQ@mail.gmail.com>
 <2035695b-b6b5-5982-a5ea-e85693e1f71f@gmx.net>
 <CAFv4g+Gh2yUdY1n+E3aAXKC46NxVoCLxmf=GR=+TK0f8myrpWg@mail.gmail.com>
 <a2f341b3-915a-aca2-12f9-88cdbee1ee41@gmx.net>
 <CAFv4g+FTvhDKD==yCsGU7hiMt6PmT78+ZiDXKbEpoDzT7hW4Cg@mail.gmail.com>
In-Reply-To: <CAFv4g+FTvhDKD==yCsGU7hiMt6PmT78+ZiDXKbEpoDzT7hW4Cg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: a.leathley@gmx.net (Andreas Leathley)

On 14.04.22 14:14, Craig Francis wrote:
> Yep, I agree with everything you have said there, and it's what George
> seems to be working towards (which I also agree with):
>
> https://github.com/Girgias/unify-typing-modes-rfc
>
Yet your RFC goes exactly against the quoted document by making the
differences between strict_types larger.

> I also cannot explain why NULL should be rejected, other than for those
> developers who see NULL as an invalid value and also use
> `strict_types=3D1`... as in, when a team of developers spends a few hund=
red
> hours adding strval() everywhere, what does that actually achieve? what =
do
> they tell the client? does it make the code easier to read? does it avoi=
d
> any bugs? or is it only for 8.1 compatibility?
I don't get why you would add strval everywhere. Why are you getting
null everywhere? In most of the examples in your RFC "null" is
specifically chosen as a default value and could easily be an empty
string (why do something like "$_POST['value'] ?? null" if you actually
want an empty string?). For the framework examples, the second argument
of these functions is the default value - it does not have to be null.
And "filter_input" I have not seen in a codebase yet, probably because
of its weird double function as retrieving an input variable and also
filtering it, with both null, false and the result as a possible return
value.

The few cases where I encountered the deprecation notice it was always a
mistake and easy to fix, and I was glad that was pointed out to me.
There is another 3.5 years until PHP 9 is likely to come out, which is a
lot of time for people to adjust their codebase. I could even see an
argument for not promoting it to a fatal error in 9.0 if so many people
need more time. Removing the deprecation and changing fundamental
aspects about the type system in PHP by auto-coercing null just so
people do not need to update their codebase seems like the worst
possible way forward.

So far, your RFC does not mention the arguments made against your
proposed changes in an understandable way. George Peter Banyard wrote
some extensive arguments and you have only included one sentence without
any of his arguments and try to refute it in the very next sentence as
not really an argument, and it was mentioned by him that coercing null
in other languages like Java has lead to problems. Comparisons to other
languages could be helpful, as NULL is not just a value in PHP - NULL in
MySQL for example also cannot be coerced and is its own distinct value
(it even has its own syntax for comparisons).

I am still bothered by the language of the RFC in general where you
often write things like ".. it hasn't been the case for everyone else",
"most developers are not in a position" and so on. Assuming you know
what everyone is doing and how everyone is doing it in an RFC does not
seem constructive. All the numbers you cite are also circumstantial and
not about the supposed problem discussed in the RFC - for example, you
assume people not using static analysis are in favor of your RFC, even
though this is pure speculation. Compared to all the other RFCs in the
last 3 years I read through I don't only disagree with this RFC, I also
think it is not very well reasoned about and does not convey the
discussions that were held about the topic on this mailing list. It
mainly contains your opinion, which seems insufficient for an RFC.