Re: NULL Coercion Consistency

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=1... as in, when a team of developers spends a few hundred 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 avoid 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.