Regarding compatibility promise, I'd also like to mention that things are quite complex now, e.g.
https://3v4l.org/VfAr4 has 4 different outputs between php 7.x and 8.x. From userland perspective, having <?php8 or <?php9 would make things a lot easier and more productive. Regards Thomas > Craig Francis <cr...@craigfrancis.co.uk> hat am 10.04.2023 14:58 CEST > geschrieben: > > > On 9 Apr 2023, at 23:10, Kamil Tekiela <tekiela...@gmail.com> wrote: > > I wonder about this every time I hear this claim. What exactly changed in > > PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may > > be a little more difficult because of some of the recent deprecations, but > > that's still years ahead of us. > > > > Most of the deprecations and changes do make sense, and while deprecating > dynamic properties is going to be a pain, I think it's going to be worth it > (like undefined variables), same with ${} string interpolation (better to be > consistent); and I know it's been mentioned in this thread, but `utf8_decode` > does get misused a lot (read the RFC as to why). > > But I do not understand "Passing null to parameter # of type string is > deprecated" specifically. > > I should note that the other coercion/type tweaks that G.B.P (Girgias) is > suggesting, and has partially implemented, do make sense: > > https://github.com/Girgias/unify-typing-modes-rfc > > And (fortunately) NULL coercion still works when concatenating NULL to a > string, adding NULL to an integer, NULL being treated as false, etc. > > One team of developers I know are still finding these issues well over a year > later (they also introduce new code that trips it as well); two other teams > specifically ignore this deprecation (far too many instances to "fix"), and > one team is still to decide what they are going to do (annoyingly they are > still using 7.4). > > Even Rector gives up and uses `(string) $var` for every variable that's a > non-nullable string, which can result in thousands of changes in a project > (that's for the ~434 function arguments being checked; personally I'd have > only gone with 335 of the ~997): > > https://github.com/rectorphp/rector-src/blob/main/rules/Php81/Rector/FuncCall/NullToStrictStringFuncCallArgRector.php > > Anyway, when PHP 9.0 makes this a type error, in the ~85% of code that isn't > using strict types, that's going to cause lots of random and unexpected > problems. > > Craig > > > > PS: I drafted this RFC, but didn't continue due to the negativity (i.e. it > would have been voted down, and then used to justify the type error): > > https://wiki.php.net/rfc/null_coercion_consistency -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php