Re: NULL Coercion Consistency

On 14.04.22 10:10, Craig Francis wrote:

My intro says "Roughly 85% scripts do not use strict_types=1", and "Roughly 33% of developers use static analysis" (source of numbers noted in my RFC)... while that does not guarantee anything, it's a fairly good indication that most developers do not care about types (in regards to coercion), or specifically, how you "see null as a real type". As an aside, I would like to include more stats (maybe WordPress install numbers?), but I couldn't think of any which were easy to source (ref reliability), or be that useful to the discussion. I have never used strict_types in any code I have ever written, and I

care about types and type coercions. Yet I do not like the strict_types distinction and I am glad that I do not need to use it, and I think we are not that far away from even reconciling these two systems. I do not mind that the string "5" can be passed to an int parameter, while passing the string "hello" will throw a type exception no matter what mode you use. With some adjustments to certain coercions the advantage of strict_types would be even more neglible - as you can pass "hello" to a boolean parameter without problems currently, and I don't like that. Looking at usage numbers and assuming that supports your point seems like a big leap to me. You are assuming these developers are making a choice while it seems quite possible that a lot of code has been written without thinking about all the implications, which is where so many bugs are coming from. In the last months reviewing code I noticed quite a few developers are copy-pasting code like crazy, or using generated code from other tools - both of which are often not well reasoned about. So this has little to do with developers not caring about methods of type coercions and more about the language permitting such code, leading to many follow-up problems. Also, this "problem" only affects the internal functions, yet you want to change it for all functions. If you use a framework and pass a value to a method of that framework, it would already have created a type error with null and a non-nullable argument for quite some time. I think you are making this out to be a bigger problem than it is. Sure, in a codebase with lots of custom code where no incoming variable is checked if it even exists there will be problems, but even then it is easily fixable. In a codebase based on a common framework it is much less of a problem, as you will probably be using lots of framework components and not mainly internal functions, and there you already have the "limitation" of not being able to pass null to a non-nullable method.