On 24 June 2026 15:24:38 BST, "Tim Düsterhus" <[email protected]> wrote:
>It is insofar relevant that deprecations have zero immediate impact. There >might be an impact once the actual removal happens, but users have at least 4 >years until the PHP version that first made them aware that something is >deprecated goes out of (security) support and they might be required to >upgrade to a PHP version where the deprecated functionality changed or was >removed. I hate this argument. Unless otherwise stated, a proposal to deprecate something is a proposal to remove / forbid it in future. The impact analysis being asked for is the impact of that removal / prohibition. That analysis can absolutely account for the fact that removal won't be immediate. For example, maybe all the uses found are in code that will need rewriting for some other reason. Or maybe there's evidence that all the uses found are in fast-moving code that is unlikely to be maintained long term. I don't think anyone is suggesting a threshold where "use in X packages" automatically disqualifies the proposal. We're just asking for the information to weigh the cost and benefit of *the end goal* that the deprecation is trying to achieve. > I am thus taking issue with the unconditional request of an “impact analysis”, which will inherently be biased due to the inability to capture and measure anticipated positive impact and thus will not help make the reader make a more informed decision. Bias is inevitable: listing the benefits of changing something without any mention of its impact on existing code is also bias. To knowingly omit information that might weaken your case would be dishonest. If you think the raw numbers don't tell the whole story, it's up to you to explain why. When I proposed to deprecate utf8_encode/decode, I looked into every single usage I could find, so I could make the case that it was used wrong more often than right. Most removals don't need that level of detail, because often some easy numbers *do* tell a clear story. > Is there some specific proposal where you feel there is a stark > mismatch between the cost for existing code and the benefit in making the language easier to learn How can anyone answer that question without some information about the cost for existing code? Are you saying that every voter should perform their own research on every proposal? I'm with Juliette on this - any proposal which doesn't have some information about expected impact will get an automatic "No" vote from me. Rowan Tommins [IMSoP]
