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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
