Re: [RFC] Deprecations for PHP 8.6

Hey Gina, Am 22.06.2026 um 15:13 schrieb Gina P. Banyard <internals@gpb.moe>: Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.6: https://wiki.php.net/rfc/deprecations_php_8_6 As a reminder, this list has been compiled over the course of the past year by different people. And as usual, each deprecation will be voted in isolation. We still have a bit of time anyone else to propose additional deprecations, and if you have write access feel free to add them directly to the RFC. Please note that with the new RFC policy rules the RFC must be finalized and in a "frozen" state by the 13th of July at the latest. Some deprecations should be non-controversial, others a bit more. If a deprecation is really controversial, it might warrant its own dedicated RFC or be dropped altogether. Best regards, Gina P. Banyard Thanks for compiling this list, I think it's more reasonable and a bit smaller than previous editions. Thanks for that. Could you please expand on the potential gains on "Deprecate ArrayIterator methods that inherit ArrayObject implementation"? A vague promise of unlocking potential optimizations is not very persuading. The "_" deprecation feels more like a change for the sake of it (consistency with a removal which has actual incoming functionality), even though there's no actual benefit for it for constants. There's no reason I can imagine why we'd ever need underscores in function call position for another language feature. I don't think we should deprecate "let". let is universally used for block-scoping in other languages. I don't think PHP should ever have block-scoping inside functions. The corresponding RFC was also declined with 50%+ of the vote. Hence I don't think we should deprecate a name which won't ever be needed. On "Deprecate changing by-reference return modifier via inheritance" - how exactly is this a LSP violation? If you assign a value without explicit "&" it'll be by-value, regardless of it being reference or not. If you put "&" there, you intentionally want a reference and you will get a warning when trying to use it. There's no magic "this value was a reference, hence this behaves differently now" in PHP, but references trivially decay to values, when used in a by-value context. This is basically covariance. There's no need to change this, and I assume there was a logic error from the author of that suggestion. One question, is "Passing objects which are interpreted as arrays" one big vote, or does each item get a vote? For array_walk(_recursive) specifically, I see some value of using it - sometimes data structures are available in object form, saving a cast ... and a cast back, which is not trivial, unless it's a stdclass. Everything else, I do agree with. Also, why would we deprecate CURLOPT_PROGRESSFUNCTION? According to https://grep.app/search?f.lang=PHP&q=CURLOPT_PROGRESSFUNCTION it's quite widely used in widely used libraries, like guzzle and symfony. And I wouldn't know what it's replacement would be? Bob