Re: Re: [RFC] Deprecations for PHP 8.6

On Tuesday, 7 July 2026 at 14:51, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > On 7 July 2026 12:54:29 BST, "Gina P. Banyard" <internals@gpb.moe> wrote: > >> https://wiki.php.net/rfc/deprecations_php_8_6 > > > >If anyone has any issues or additional proposals they can still be added or amended. > >If none are added or amended, I will initiate a call to vote next week. > > > I just skimmed through the page, and counted 35 proposals, of which only 8 had any analysis or > discussion of the impact on existing code. > > Several more have had discussions of their impact in this thread, but the conclusions have not > been summarised in the RFC for voters to see. > > ---- > > As I stated previously, if the vote is called with the RFC in the current state, I will cast 27 > "no" votes, and only examine the remaining 8 proposals in detail. > > ---- You are free to do as you please. > The reason we require votes to pass with a two-thirds majority is to maintain the status quo by > default. Changes, whether they are adding features or removing them, need to be weighed on a balance > of cost vs benefit. > > It is not reasonable to expect every voter to independently research the costs of every > proposal. It is up to the person proposing each change to make an honest and informed case for that > balance, rather than presenting only advantages or gut feelings. > > I urge everyone whose name is on this RFC to review its content with that in mind. There are no guidelines on what constitutes a "impact assessment". Especially as qualitative assessments or the cost of keeping it in the language seem to not count. Unless the people that actively care about this provide concrete methods on how RFC authors can do such an assessment that does not require downloading gigabytes (possibly even terabytes) of barely representative OSS code, building an AST or static analysis tool, and then interpreting result in a way that is suitable for the people that care, I will not be engaging in providing metrics for the sake of providing metric that bear no usefulness for certain proposals. Best regards, Gina P. Banyard