Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119859
Date: Mon, 10 Apr 2023 16:37:53 +0200 (CEST)
To: Craig Francis <craig@craigfrancis.co.uk>,
	PHP internals <internals@lists.php.net>
Message-ID: <114465957.2449454.1681137473474@email.ionos.de>
In-Reply-To: <E1957E21-F069-4E78-98F1-DAF14EE3D92E@craigfrancis.co.uk>
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAGBsUrcQWKc+JD2adprcgdqNAKr==McFeoYO3WF3pR2qxgon2g@mail.gmail.com>
 <CAMXcktN64EsoErjbFzdWe+qzM5RVYNR98WO8xcLOYxeYCK=NiA@mail.gmail.com>
 <CADK1yXJMgSrjCahW2_G-C=ye=mBiuWtQAKyJrbFc-W4ODL6fZw@mail.gmail.com>
 <CAGBsUrd=X6d8eZsSjaz+hQYLTCPCHPExhsawWhr8BWD=prEb1Q@mail.gmail.com>
 <E1957E21-F069-4E78-98F1-DAF14EE3D92E@craigfrancis.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Importance: Normal
UI-OutboundReport: notjunk:1;M01:P0:vkfEpr0CEBE=;XG9epbu+f3M1PQ1DtygFpQnDzE2
 9U7FqZHUmliCuBeQ5FD6f72sNe/4yVYxY5zAVQd1eV6vR6Hb/sk3A8jkLF+qocg8gzuaYvOa7
 pFFUfKatDaNnLZ5JqAHXVA/j5skIq2nKiLLLE2MUpGv3hYTfJB41YanEuiVODkZpzh7hOECa9
 TAG4HglZN0mn7oHjty1gHrdogsDCollyMbMe5qJT6ew37ceks++uFd1B2fWAV5rnN0U6t3XgP
 zFY+RksSarM8afJ1JVxjmoFumZisvNaVgFnP6eHW6+RHi7MJFPngpZt1TpSEEbpJ5TCupQOp5
 QRYzyU8goMMSzAVbRJGAmF376aQcmS4pH7f9vGbZkX90MagolcIuaXLhZXHMytjCE6AejoILq
 M/0u1P6qcustJ9jCaNWU/dNE0CaLutburFXOLP7nQQkpS6vNsXReBAEdZQQEwiIbWjCWkNj87
 Otmo6JXe9UrYvvA1fV6CqOeIzgqtzrX2kLtPeKe/ZeEaLAZV1jV02UfXrXwNVmQ+nYxuitCcL
 hklDmEC5LhLyoxfLp4nEQ25SSlBqfk0K2d7U0GJP0adC3A4GB9704PH0Jg/AAemSj/5CMt3n0
 v7+FtYwLb1bnTdw8zkLaje8AeuxKMs4vrMKpFKFRVue6VpZZtIqET4seUV0mhKlGp1oMJYT/K
 U4WXtONMdhjCmrjl9iEs
Subject: Re: [PHP-DEV] Future stability of PHP?
From: mails@thomasbley.de (Thomas Bley)

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 <craig@craigfrancis.co.uk> hat am 10.04.2023 14:58 CEST geschrieben:
> 
>  
> On 9 Apr 2023, at 23:10, Kamil Tekiela <tekiela246@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