# [RFC] Deprecations for PHP 8.6 - Thread: https://externals.io/message/131452 - Original archive: https://news-web.php.net/php.internals/131452 - Started by Gina P. Banyard on 2026-06-22T13:13:19+00:00 - Messages: 99 - RFC: Deprecations for PHP 8.6 (Accepted) — https://externals.io/rfc/deprecations_php_8_6.md - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/131452.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #131452 — Gina P. Banyard — 2026-06-22T13:13:19+00:00 URL: https://externals.io/message/131452#131452 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 --- ## #131457 — Nicolas Grekas — 2026-06-22T15:16:03+00:00 URL: https://externals.io/message/131452#131457 · In reply to: #131452 Hi Gina, Le lun. 22 juin 2026, 15:19, Gina P. Banyard a écrit : > 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 > After a quick check, I'm wondering about > Deprecate `CURLOPT_PROGRESSFUNCTION` for `curl_setopt()` Can you expand on this? Thanks, Nicolas --- ## #131461 — Juliette Reinders Folmer — 2026-06-22T15:58:02+00:00 URL: https://externals.io/message/131452#131461 · In reply to: #131452 > 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 Hi Gina, thanks for working on this. Unfortunately none of the proposals contain a proper impact analysis. I don't hold this against you personally, I know this RFC is the work of quite a few people, but I do find it terribly irresponsible that the impact of these deprecations is not outlined for the voters to help their decision making. In my experience, it would be quite trivial to create an impact analysis for the fast majority (~70%) of the current proposals using PHP_CodeSniffer and PHPCompatibility. I'd be happy to help get that set up if there is interest in adding such an analysis to the proposals. Smile, Juliette --- ## #131462 — Rowan Tommins [IMSoP] — 2026-06-22T16:11:17+00:00 URL: https://externals.io/message/131452#131462 · In reply to: #131452 >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 The one that stands out to me at first glance is the `_()` alias for `gettext()` I understand the motivation, but removing it is likely to be extremely disruptive, particularly paired with banning it as an identifier so users can't polyfill it. `_()` is basically the canonical way to use gettext in every language it's been ported to. The idea is that you can write code and templates with hard-coded English/base-language strings, and wrap them with a small amount of punctuation rather than extra words. While replacement would be relatively straightforward, affected codebases are likely to have thousands of uses, and the end result would be a reduction in readability. If we want to go down this route, we need a stronger justification than is given - does it actually cause a *problem* reserving it only in class-like context, or is the proposal just for neatness? Rowan Tommins [IMSoP] --- ## #131463 — Rowan Tommins [IMSoP] — 2026-06-22T16:26:39+00:00 URL: https://externals.io/message/131452#131463 · In reply to: #131462 >The one that stands out to me at first glance is the `_()` alias for `gettext()` > Sorry for the double reply, but I just checked the comments on the PR linked from the RFC https://github.com/php/php-src/pull/15360 There's a comment from Ilija saying that even the existing deprecation probably isn't needed, further weakening the case. There's another comment saying that class_alias already shows the deprecation, which 3v4l confirms: https://3v4l.org/QEcZs Rowan Tommins [IMSoP] --- ## #131464 — Bob Weinand — 2026-06-22T16:38:29+00:00 URL: https://externals.io/message/131452#131464 · In reply to: #131452 Hey Gina, Am 22.06.2026 um 15:13 schrieb Gina P. Banyard : 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 --- ## #131467 — Rowan Tommins [IMSoP] — 2026-06-22T17:14:42+00:00 URL: https://externals.io/message/131452#131467 · In reply to: #131464 > >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. The RFC raised was for a unique-to-PHP concept of a special "scope block" using the "let" keyword in a way no other language does. Taking that vote to mean nobody wants block scoping is a huge stretch. In fact, I think block scoping would be a really useful addition to the language, and hope someone brings forward a proposal which more closely mirrors other Algol-descended languages. For me, it is a prerequisite for auto-capture closures, because it gives a way to unambiguously opt *out* of capture; but it also has plenty of other uses, just as it does in other languages. Whether we need to reserve the name to allow that, I will leave to those who know more about the parser. Rowan Tommins [IMSoP] --- ## #131468 — Theodore Brown — 2026-06-22T17:22:58+00:00 URL: https://externals.io/message/131452#131468 · In reply to: #131464 > 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? Per the PHP documentation for `CURLOPT_PROGRESSFUNCTION` [1]: > deprecated as of cURL 7.32.0. Use `CURLOPT_XFERINFOFUNCTION` instead. The cURL page for this option also states that it is deprecated since 7.32.0. [2] It probably would be good to update the RFC to clarify this. Sincerely, Theodore [1]: https://www.php.net/manual/en/curl.constants.php#constant.curlopt-progressfunction [2]: https://curl.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html --- ## #131475 — Osama Aldemeery — 2026-06-22T18:41:34+00:00 URL: https://externals.io/message/131452#131475 · In reply to: #131461 On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer < php-internals_nospam@adviesenzo.nl> wrote: > > > 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 > > > Hi Gina, thanks for working on this. > > Unfortunately none of the proposals contain a proper impact analysis. > > I don't hold this against you personally, I know this RFC is the work of > quite a few people, but I do find it terribly irresponsible that the impact > of these deprecations is not outlined for the voters to help their decision > making. > > In my experience, it would be quite trivial to create an impact analysis > for the fast majority (~70%) of the current proposals using PHP_CodeSniffer > and PHPCompatibility. > > I'd be happy to help get that set up if there is interest in adding such > an analysis to the proposals. > > Smile, > Juliette > > Hi Juliette, Thanks for raising this. For the *return-in-finally deprecation*, I did run an impact analysis. I just kept it out of the RFC entry itself, partly to keep the entry short, partly because I'd already shared the core of it in my original pre-RFC message on this list ( https://externals.io/message/131393#131393 - which lists all 12 affected sites), and partly because I hadn't gotten around to reposting it in this thread yet. So here it is, for you and for anyone else following along... I compiled the ~5000 most-installed Composer packages with the patched build and collected every site that triggers the new deprecation. It shows up in 12 places across 9 packages, about 0.18%. Reading each one: - 3 are latent bugs the deprecation would catch, where the finally return discards an exception the try can throw - the other 9 either deliberately rely on the discard or are harmless The full write-up, with the per-site breakdown and the script to reproduce it, is here: https://github.com/aldemeery/php-rfcs/tree/master/deprecate-return-in-finally Thanks, Osama --- ## #131480 — Juliette Reinders Folmer — 2026-06-22T19:58:47+00:00 URL: https://externals.io/message/131452#131480 · In reply to: #131475 > On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer > > wrote: > > > > […] > > Unfortunately none of the proposals contain a proper impact analysis. > > > For the *return-in-finally deprecation*, I did run an impact analysis. > I just kept it out of the RFC entry itself, partly to keep the entry > short, partly because I'd already shared the core of it in > my original pre-RFC message on this list > (https://externals.io/message/131393#131393 - which lists all 12 > affected sites), and partly > because I hadn't gotten around to reposting it in this thread yet. > ... > The full write-up, with the per-site breakdown and the script to > reproduce it, is here: > https://github.com/aldemeery/php-rfcs/tree/master/deprecate-return-in-finally > Thanks Osama! And yes, I remember you posting those impact analysis results to the list. I believe it would be good to include that summary in the RFC text. Would make your proposal the (positive) exception to the rule ;-) Smile, Juliette --- ## #131481 — Ayesh Karunaratne — 2026-06-22T20:16:06+00:00 URL: https://externals.io/message/131452#131481 · In reply to: #131468 > Per the PHP documentation for `CURLOPT_PROGRESSFUNCTION` [1]: > > > […] > > The cURL page for this option also states that it is deprecated since 7.32.0. [2] > > It probably would be good to update the RFC to clarify this. > > Sincerely, > Theodore > > [1]: https://www.php.net/manual/en/curl.constants.php#constant.curlopt-progressfunction > [2]: https://curl.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html Although libcurl documents `CURLOPT_PROGRESSFUNCTION` and `CURLOPT_XFERINFOFUNCTION` as separate options, they are effectively the same kind of API from PHP userland’s perspective: both register a progress callback and use the same return convention to abort a transfer. Because of that, ext/curl could internally map `CURLOPT_PROGRESSFUNCTION` to libcurl’s `CURLOPT_XFERINFOFUNCTION` instead of introducing a PHP deprecation for the legacy constant. The only `CURL*` PHP constant we deprecated in PHP was `CURLOPT_BINARYTRANSFER`[^1], which had very small usage then and was already a no-op option. In PHP 5.6, six constants[^4] were removed. Since this constant is used frequently, and we can rewrite it to use `XFERINFOFUNCTION`, we can simplify things for hundreds of library maintainers. This is especially true because `CURLOPT_PROGRESSFUNCTION` and `CURLOPT_XFERINFOFUNCTION` are practically identical within PHP. We already maintain BC for constants deprecated in libcurl, but still support them in PHP without any deprecation notices: - CURLINFO_HTTP_CODE[^2] (deprecated in libcurl 7.10.8) - CURLOPT_ENCODING[^3] (deprecated in libcurl 7.21.6) The only Curl constant I'd propose to deprecate would be CURLE_OBSOLETE[^5]. It is still declared in PHP but is no longer[^6] used in libcurl. [^1]: https://php.watch/codex/CURLOPT_BINARYTRANSFER [^2]: https://php.watch/codex/CURLINFO_HTTP_CODE [^3]: https://php.watch/codex/CURLOPT_ENCODING [^4]: https://php.watch/codex?search=CURL [^5]: https://php.watch/codex/CURLE_OBSOLETE [^6]: https://github.com/curl/curl/blob/master/include/curl/curl.h --- ## #131483 — tim@bastelstu.be — 2026-06-22T20:54:51+00:00 URL: https://externals.io/message/131452#131483 · In reply to: #131461 Hi > Unfortunately none of the proposals contain a proper impact analysis. Unless your definition of “proper” differs from mine, this is false. As an example, the “Deprecate using "let" as an identifier” deprecation proposal contains this paragraph: > The analysis performed at part of the let construct (Block Scoping) RFC indicated an insignificant usage of “let” in the wild. which is more than “none of the proposals”. The same is true for “Deprecate returning from a finally block” proposal. But as every year: - Harmful functionality does not become less harmful, just because it is widely used. - Deprecations are not a breaking change. This is even explicitly written down in the PHP project’s policy as of the https://wiki.php.net/rfc/policy-release-process-update RFC. A majority of the deprecation messages provide actionable advice to the user, and all of the proposals have a proper justification - even if you might personally disagree with it. As an example, I don't personally agree with the deprecation of `metaphone()`, see https://news-web.php.net/php.internals/130806. Best regards Tim Düsterhus --- ## #131484 — tim@bastelstu.be — 2026-06-22T21:01:16+00:00 URL: https://externals.io/message/131452#131484 · In reply to: #131464 Hi > 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? This looks like an editorial error. The deprecation is only listed in the table of contents, but has no dedicated section. The TOC entry was added on January, 26th by devnexen: https://wiki.php.net/rfc/deprecations_php_8_6?do=diff&rev2%5B0%5D=1767204361&rev2%5B1%5D=1769465262&difftype=sidebyside Best regards Tim Düsterhus --- ## #131485 — Juliette Reinders Folmer — 2026-06-22T21:41:48+00:00 URL: https://externals.io/message/131452#131485 · In reply to: #131483 > Hi > > > > […] > > Unless your definition of “proper” differs from mine, this is false. > As an example, the “Deprecate using "let" as an identifier” > deprecation proposal contains this paragraph: > > > […] > > which is more than “none of the proposals”. The same is true for > “Deprecate returning from a finally block” proposal. > > But as every year: > > - Harmful functionality does not become less harmful, just because it > is widely used. > - Deprecations are not a breaking change. This is even explicitly > written down in the PHP project’s policy as of the > https://wiki.php.net/rfc/policy-release-process-update RFC. > > A majority of the deprecation messages provide actionable advice to > the user, and all of the proposals have a proper justification - even > if you might personally disagree with it. As an example, I don't > personally agree with the deprecation of `metaphone()`, see > https://news-web.php.net/php.internals/130806. > Tim, please don't try to gaslight me. The fact that one out of twentyfive proposals has some vague statement about the impact, without any details of what was analysed or how, without definition of "insignificant", and without a link to details giving credibility to that statement, only goes to highlight that these proposals lack a proper impact analysis. I agree though that the "finally block" proposal is the only positive exception to this. Other than that, I did not express an opinion on the details of the individual proposals, but (as every year) you seem to draw conclusions based on things I never said. The fact that you even feel the need to point out that "deprecations are not a breaking change" is extremely offensive in and of itself. You should know better. Please don't do that. Smile, Juliette --- ## #131486 — Seifeddine Gmati — 2026-06-22T22:20:34+00:00 URL: https://externals.io/message/131452#131486 · In reply to: #131452 > 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 > Hi Gina, Thank you the RFC. Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). Cheers, Seifeddine. --- ## #131487 — Morgan — 2026-06-22T23:46:26+00:00 URL: https://externals.io/message/131452#131487 · In reply to: #131452 > > 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. > Is `spl_object_hash()` still useful? The string it creates used to be quite a bit more complex, but eventually it became equivalent to str_pad(dechex(spl_object_id($obj)), 16, '0', STR_PAD_LEFT) . '0000000000000000' I.e., it provides exactly the same content as spl_object_id, but in a much more obtuse way. For anyone _needing_ that format, the polyfill is just above. I suppose there might be changes in the future which will make the hash more useful (parallelism where objects are created simultaneously and independently), but then it would be `spl_object_id()` that has trouble coping. --- ## #131491 — youkidearitai — 2026-06-23T06:29:53+00:00 URL: https://externals.io/message/131452#131491 · In reply to: #131487 Hi, Gina and Internals I agree deprecate that "Passing object for $vars parameter of `mb_convert_variables()`". However, I have other opinion.(A little bit) mb_convert_variable and mb_convert_encoding parameter of $encoding is different behavior of `$encoding = "auto"`. If we will decide that mb_convert_variable is deprecate and delete, We need think that behavior. Anyway, This deprecate of PHP 8.6 is okay to me. Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai --- ## #131492 — Sjoerd Langkemper — 2026-06-23T07:20:45+00:00 URL: https://externals.io/message/131452#131492 · In reply to: #131452 I would like to add the dechunk filter to the deprecation list, but there is some discussion around how to implement that since it is used internally by the HTTP fopen wrapper. More information here: https://github.com/php/php-src/issues/21983 https://github.com/php/php-src/pull/22036 https://github.com/php/php-src/pull/22396/changes Regards, Sjoerd Langkemper --- ## #131493 — Nicolas Grekas — 2026-06-23T07:26:41+00:00 URL: https://externals.io/message/131452#131493 · In reply to: #131492 Le mar. 23 juin 2026, 09:23, Sjoerd Langkemper a écrit : > I would like to add the dechunk filter to the deprecation list, but there > is some discussion around how to implement that since it is used internally > by the HTTP fopen wrapper. > > More information here: > https://github.com/php/php-src/issues/21983 > https://github.com/php/php-src/pull/22036 > https://github.com/php/php-src/pull/22396/changes > > Regards, > > Sjoerd Langkemper > Please don't, it's used in userland also. Cheers --- ## #131494 — Sjoerd Langkemper — 2026-06-23T07:42:47+00:00 URL: https://externals.io/message/131452#131494 · In reply to: #131493 > Please don't, it's used in userland also. Thanks, that is interesting. Do you have more information about this? Where and how is it used? Do you have an example? Regards, Sjoerd Langkemper --- ## #131495 — Nicolas Grekas — 2026-06-23T07:46:43+00:00 URL: https://externals.io/message/131452#131495 · In reply to: #131494 Le mar. 23 juin 2026, 09:43, Sjoerd Langkemper a écrit : > > > Please don't, it's used in userland also. > > > Thanks, that is interesting. Do you have more information about this? > Where and how is it used? Do you have an example? > > Regards, > > Sjoerd Langkemper > Sure, here is the pointer: https://github.com/symfony/symfony/blob/dce1b899ab0c0e4cef9159c083ef535387a8db12/src/Symfony/Component/HttpClient/Response/NativeResponse.php#L188 --- ## #131498 — Gina P. Banyard — 2026-06-23T10:50:17+00:00 URL: https://externals.io/message/131452#131498 · In reply to: #131486 > Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). > > > […] If we provide a new set of by-reference parameters I think we would want to have the possibility to do: - inout for mutable references - in for immutable references - out for out parameters (such as the $matches parameter of `preg_match()`) where the input value is explicitly discarded Thus, I would prefer to reserve them in bulk and if it turns out we don't use them we can always remove the restriction. Best regards, Gina P. Banyard --- ## #131499 — Gina P. Banyard — 2026-06-23T10:54:15+00:00 URL: https://externals.io/message/131452#131499 · In reply to: #131487 > > > […] > Is `spl_object_hash()` still useful? The string it creates used to be > quite a bit more complex, but eventually it became equivalent to > > str_pad(dechex(spl_object_id($obj)), 16, '0', STR_PAD_LEFT) . > '0000000000000000' > > I.e., it provides exactly the same content as spl_object_id, but in a > much more obtuse way. For anyone _needing_ that format, the polyfill is > just above. > > > I suppose there might be changes in the future which will make the hash > more useful (parallelism where objects are created simultaneously and > independently), but then it would be `spl_object_id()` that has trouble > coping. If you provide me with text proposal (ideally in DokuWiki format, but markdown is fine) I'm happy to include it in the bulk RFC. I will however not be writing it myself. Best regards, Gina P. Banyard --- ## #131501 — Seifeddine Gmati — 2026-06-23T11:44:46+00:00 URL: https://externals.io/message/131452#131501 · In reply to: #131498 > > > > Overall, everything looks good, however, i object (although not voting) to deprecating `in` and `out`, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. `inout` on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in `inout $x`, is it the type or modifier ). > > > If we provide a new set of by-reference parameters I think we would want to have the possibility to do: > > inout for mutable references > in for immutable references > out for out parameters (such as the $matches parameter of `preg_match()`) where the input value is explicitly discarded > > > Thus, I would prefer to reserve them in bulk and if it turns out we don't use them we can always remove the restriction. > > Best regards, > > Gina P. Banyard > The idea is interesting, i would say it's fine to mark them as reserved then. I assumed the only reason for reserving them was generics. Cheers, Seifeddine. --- ## #131510 — Daniel Scherzer — 2026-06-23T23:58:11+00:00 URL: https://externals.io/message/131452#131510 · In reply to: #131452 > 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 managing this - amazing how fast time flies. I've added a few new entries, including the `spl_object_hash()` deprecation suggested by Morgan. -Daniel --- Next page: https://externals.io/message/131452.md?page=2