On Thu, 14 Apr 2022 at 10:01, Andreas Leathley <a.leath...@gmx.net> wrote:
> 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. > 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 > 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, Actually, that's exactly what I see happening - NULL is passed to these internal functions without any thought, and unlike arrays/resources/etc which cannot be sensibly coerced, NULL coercion has been fine, and has worked for (as long as I can tell) forever. Back to the most simple example I can think of: $search = filter_input(INPUT_GET, 'q'); // Or any of the framework examples. echo 'Results for ' . htmlspecialchars($search); It does not matter if the request explicitly set "/?q=" in the URL or not; `filter_input()` and frameworks show there is a difference by returning NULL or an Empty String... but most of the time, no thought is given to that difference, developers just expect it to work. 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. > Yep, and that's why I'm in favour of stopping the broken/weird coercions... it's just that NULL is different, and it's fine (as noted, there are some developers who use it part of their strict type checking, but that seems to be fairly unusual). > Also, this "problem" only affects the internal functions, yet you want to > change it for all functions. > My RFC is focused on the backwards compatibility problems for internal functions... user defined functions are only included for consistency reasons (keeping the spirit of the original RFC), because they probably should coerce NULL, like how they coerce integers to strings, etc. 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. > Yep, and that has caused... I wouldn't say problems, but minor confusion? Craig
