[PHP-DEV] [RFC] Deprecations for PHP 8.6

Mailing Lists php.internals
1

Hello internals,

It is this time of year again where we proposed a list of deprecations to add in 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

2

Hi Gina,

Le lun. 22 juin 2026, 15:19, Gina P. Banyard internals@gpb.moe 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

3

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

···

On 22-6-2026 15:13, Gina P. Banyard 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](https://wiki.php.net/rfc/deprecations_php_8_6)
4

On 22 June 2026 14:13:19 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:

Hello internals,

It is this time of year again where we proposed a list of deprecations to add in PHP 8.6:

PHP: 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]

5

On 22 June 2026 17:11:17 BST, "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk> wrote:

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 Deprecate using "_" as a class name by Girgias · Pull Request #15360 · php/php-src · GitHub

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: Online PHP editor | output for QEcZs

Rowan Tommins
[IMSoP]

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:

PHP: 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

7

On 22 June 2026 17:38:29 BST, Bob Weinand <bobwei9@hotmail.com> wrote:

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]

8

On Mon, June 22, 2026 at 10:38 Bob Weinand wrote:

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

9

On Mon, Jun 22, 2026 at 6:59 PM Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> wrote:

On 22-6-2026 15:13, Gina P. Banyard 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](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:

Thanks,
Osama