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

Mailing Lists php.internals
41

On Mon, Jun 29, 2026 at 1:56 PM Derick Rethans <derick@php.net> wrote:

I think I am not in favour of the following:

  • Deprecate returning from a finally block

If somebody uses a return in a finally block, than this could just
as well be intentional.

Hi Derick,

Yes, as you have probably already seen in the RFC, 9 out of the 12 instances across the top ~5000 packages
were intentional, but the proposal is not really aimed at intent.
Deprecating it takes no capability away from anyone doing this on purpose, since the same result can still
be expressed in other ways, sometimes by just moving the return out of the finally, but at the same time it protects
the people who do not pay attention to it (which could even be some of those deliberately using it today, once they add a return or a throw in the try later and its result silently disappears).

I also want to bring up again that even though I am suggesting a deprecation, I am still genuinely interested to know whether someone
feels a warning, or even a notice, would fit better, so that if the deprecation gets voted down we would at least have an impression of where people stand.

The main point here is that silently discarding the in-flight state, without giving a single hint about it, is a footgun, and that silent part is really the concern here.
A return in finally quietly discarding an in-flight return value, and more importantly an in-flight exception, so a thrown error can just disappear with nothing reported anywhere.

Regards,
Osama

42

Hello Internals,

I have updated the RFC to include a deprecation proposal for the
`list()` construct.

ref: PHP: rfc:deprecations_php_8_6

Cheers,
Seifeddine.

43

Before I add it to the RFC, I wanted to get a quick temperature check on whether people think it is finally time to deprecate and eventually remove open_basedir?

The argument is that it’s an old “hack” designed in an era when most people ran php on shared hosts via mod_php (Apache) under the same username, necessitating a way to separate users.
For any hosting provider prioritizing security, better solutions exist now (VPC, php-fpm with different user pools, etc…) Therefore, this solution has outlived its usefulness and only adds complexity & overhead to file operations across the codebase.

···

Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

44

Am 2026-06-29 19:07, schrieb Ilia:

Before I add it to the RFC, I wanted to get a quick temperature check on
whether people think it is finally time to deprecate and eventually remove
open_basedir?

I would be very much in favor of it, but please make sure to find the (various) existing discussions to reference. Given the amount of related discussion that have happened before, it might also make sense to do this as its own RFC.

Best regards
Tim Düsterhus

45

On 29 June 2026 18:07:05 BST, Ilia <ilia@ilia.ws> wrote:

On Mon, Jun 22, 2026 at 9:19 AM Gina P. Banyard <internals@gpb.moe> wrote:

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.

Before I add it to the RFC, I wanted to get a quick temperature check on
whether people think it is finally time to deprecate and eventually remove
open_basedir?

Yes, but for PHP 9.

cheers
Derick

46

Hi

Am 2026-06-29 19:33, schrieb Derick Rethans:

Before I add it to the RFC, I wanted to get a quick temperature check on
whether people think it is finally time to deprecate and eventually remove
open_basedir?

Yes, but for PHP 9.

To make sure we're on the same page: Are you proposing that `open_basedir` should only be deprecated starting with PHP 9 (which means that the removal would happen in PHP 10)?

Best regards
Tim Düsterhus

47

On 29/06/2026 17:37, Seifeddine Gmati wrote:

Hello Internals,

I have updated the RFC to include a deprecation proposal for the
`list()` construct.

ref: PHP: rfc:deprecations_php_8_6

I don't think it makes sense to deprecate list() if we're not deprecating array() - they're exact counterparts, and both replaced by the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4, but as a replacement for list() was only added in PHP 7.1.

I agree that it's not immediately clear that array() constructs and list() extracts, but I think your example is unfair, because both array($a, $b) and list("a" => $a, "b" => $b) are also valid.

A possible justification would be that one is more common than the other, but right now there's no discussion or analysis of that. (Which as I've said elsewhere in this thread will be an automatic "No" vote from me if it's still the case at voting time.)

--
Rowan Tommins
[IMSoP]

48

I have updated the RFC to include a deprecation proposal for the
`list()` construct.

ref: PHP: rfc:deprecations_php_8_6

Hi Seifeddine,
I understand the reasoning behind freeing up the `list` keyword and
having a canonical way to destructure an array. However, I would argue
that the scale of this BC break far outweighs the benefits.

A quick GitHub code search shows 7 million[^1] hits for "list(" in PHP
files. If we deprecate and eventually drop `list()` in PHP 9, we can
safely assume that a large portion of existing code will fail to
compile in PHP 9.

Furthermore, the documentation for `list()` offers no hint that `[]`
is preferred over `list()`, and I would also argue that there is no
reason to prefer one over the other. Code-style guides can dictate a
project's or library's conventions, but we should take a more
conservative approach if we really have a strong technical reason to
prefer one syntax over another.

Based on the RFC text, aside from freeing up the `list` keyword for
potential future use, I do not see a sufficiently strong technical
reason to deprecate `list()`.

Thank you.

[^1]: Code search results · GitHub

49

On Mon, 29 Jun 2026 at 18:51, Ayesh Karunaratne <ayesh@php.watch> wrote:

> I have updated the RFC to include a deprecation proposal for the
> `list()` construct.
>
> ref: PHP: rfc:deprecations_php_8_6
>

Hi Seifeddine,
I understand the reasoning behind freeing up the `list` keyword and
having a canonical way to destructure an array. However, I would argue
that the scale of this BC break far outweighs the benefits.

A quick GitHub code search shows 7 million[^1] hits for "list(" in PHP
files.

That 7 million figure is misleading, as it also matches methods and
functions with a `list` suffix. Excluding forks, archived, generated,
and vendored code, and searching only for ` list($` brings it down to
roughly 1 million:

[...] If we deprecate and eventually drop `list()` in PHP 9, we can
safely assume that a large portion of existing code will fail to
compile in PHP 9.

That's the purpose of the deprecation period: like any feature or
syntax that gets removed, it gives people time to migrate away from
the old construct. In this case the migration is purely mechanical,
and the RFC already provides a one-liner for it: `ast-grep run
--pattern 'list($$$ARGS)' --rewrite '[$$$ARGS]' --lang php -U`

Furthermore, the documentation for `list()` offers no hint that `[]`
is preferred over `list()`, and I would also argue that there is no
reason to prefer one over the other. Code-style guides can dictate a
project's or library's conventions, but we should take a more
conservative approach if we really have a strong technical reason to
prefer one syntax over another.

`list()` does not currently recommend `[]` because it has not yet been
deprecated, and it exists only as an alternative syntax for `[]` in
write positions ( post 7.1 ). Once deprecated, the documentation and
coding styles will have to adopt the change. A library's stylistic
preference for a redundant syntax should not dictate language design;
it should follow the change.

Based on the RFC text, aside from freeing up the `list` keyword for
potential future use, I do not see a sufficiently strong technical
reason to deprecate `list()`.

Freeing up the `list` keyword for a potential future `list` type is
indeed the main motivation, but not the only one: it also simplifies
the language grammar and leaves newcomers with fewer things to learn.

Cheers,
Seifeddine.

50

On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 29/06/2026 17:37, Seifeddine Gmati wrote:
> Hello Internals,
>
> I have updated the RFC to include a deprecation proposal for the
> `list()` construct.
>
> ref: PHP: rfc:deprecations_php_8_6

I don't think it makes sense to deprecate list() if we're not
deprecating array() - they're exact counterparts, and both replaced by
the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4,
but as a replacement for list() was only added in PHP 7.1.

I'm actually in favor of deprecating `array()` too, and I raised this
on the #php-internals Discord channel. The motivation there is weaker
though: unlike `list`, deprecating `array()` does not free up a
keyword, since `array` remains a type. The grammar simplification and
having fewer things for newcomers to learn still apply, and IMO are
good reasons on their own. If there's appetite for it, I'm happy to
add it to the RFC.

I agree that it's not immediately clear that array() constructs and
list() extracts, but I think your example is unfair, because both
array($a, $b) and list("a" => $a, "b" => $b) are also valid.

The example isn't claiming the two forms can't be written the other
way around. The point is purely about how they read: set next to
`array("a" => $a, "b" => $b)`, the construct `list($a, $b)` looks like
it builds some kind of list value, a sibling of `array()`, when in
fact it constructs nothing and instead pulls values out of an existing
array.

And `list("a" => $a, "b" => $b)` actually reinforces the case. In PHP
you can't tell a construct from a function call just by looking at it,
so someone reading that for the first time has no way to understand
why a "funtcion" called `list` is being called in a write context with
key/value pairs. The name actively misleads.

A possible justification would be that one is more common than the
other, but right now there's no discussion or analysis of that. (Which
as I've said elsewhere in this thread will be an automatic "No" vote
from me if it's still the case at voting time.)

I don't think relative frequency is the core justification here, so
I'd rather not anchor the RFC on usage numbers. The case rests on the
keyword being freed for a potential future `list` type, grammar
simplification, and the readability point above, regardless of which
form is more common.

Cheers,
Seifeddine.

51

On 22.06.26 21:13, Gina P. Banyard 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

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

Hello Internals,

I added *Deprecate using “namespace” as a class constant or static property name* to the RFC:

--

Cheers
Nick

52

Hi,

On Mon, Jun 29, 2026 at 7:09 PM Ilia <ilia@ilia.ws> wrote:

On Mon, Jun 22, 2026 at 9:19 AM Gina P. Banyard internals@gpb.moe wrote:

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.

Before I add it to the RFC, I wanted to get a quick temperature check on whether people think it is finally time to deprecate and eventually remove open_basedir?

There are valid use cases for open_basedir where it can improve security of the application. It just cannot be relied on as a sendbox in general sense but removing it would be a mistake IMHO - not even mentioning that it would require migration for many applications that might depend on it. So -1 on it especially with such a late notice.

Kind regards,

Jakub

53

On 2026-06-30 06:29, Seifeddine Gmati wrote:

That 7 million figure is misleading, as it also matches methods and
functions with a `list` suffix. Excluding forks, archived, generated,
and vendored code, and searching only for ` list($` brings it down to
roughly 1 million:
Code search results · GitHub

You can bring it back up to ~2.4 million with a regular expression:

54

On Mon, Jun 22, 2026 at 6:44 PM Bob Weinand <bobwei9@hotmail.com> wrote:

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.

Hi Bob,

Sorry for the late reply.

Thank you for the correction. Would you suggest I remove that sentence
from the proposal or that I retract the proposal?

55

On Mon, 29 Jun 2026, Tim Düsterhus wrote:

Am 2026-06-29 19:33, schrieb Derick Rethans:

> > Before I add it to the RFC, I wanted to get a quick temperature
> > check on whether people think it is finally time to deprecate and
> > eventually remove open_basedir?
>
> Yes, but for PHP 9.

To make sure we're on the same page: Are you proposing that
`open_basedir` should only be deprecated starting with PHP 9 (which
means that the removal would happen in PHP 10)?

Sortof. I don't think it'd be good to deprecate it now, and then remove
it next year — in case the next release will be PHP 9 instead of PHP
8.7. I think a year is not long enough as deprecation period for this
one.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud
Author of Xdebug. Like it? Consider supporting me: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social

56

Hey Volker,

Am 01.07.2026 um 15:32 schrieb Volker Dusch <edorian@php.net>:

On Mon, Jun 22, 2026 at 6:44 PM Bob Weinand <bobwei9@hotmail.com> wrote:

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.

Hi Bob,

Sorry for the late reply.

Thank you for the correction. Would you suggest I remove that sentence
from the proposal or that I retract the proposal?

Given that it seems the whole argument in favour of that deprecation is flawed, I would suggest a complete retraction.

Thanks,
Bob

57

Hi

Am 2026-06-29 20:37, schrieb Seifeddine Gmati:

I'm actually in favor of deprecating `array()` too, and I raised this
on the #php-internals Discord channel. The motivation there is weaker
though: unlike `list`, deprecating `array()` does not free up a
keyword, since `array` remains a type. The grammar simplification and
having fewer things for newcomers to learn still apply, and IMO are
good reasons on their own. If there's appetite for it, I'm happy to
add it to the RFC.

FWIW: I still have a rough draft to make `array()` (or rather: all non-object types) proper functions that effectively would “stand in” as cast operators. For `array()` specifically this would allow a named-argument style of defining arrays with “unquoted keys”: `array(foo: 1, bar: 2)`.

Best regards
Tim Düsterhus

58

On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati azjezz@carthage.software wrote:

On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 29/06/2026 17:37, Seifeddine Gmati wrote:

Hello Internals,

I have updated the RFC to include a deprecation proposal for the
list() construct.

ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct

I don’t think it makes sense to deprecate list() if we’re not
deprecating array() - they’re exact counterparts, and both replaced by
the syntax. Indeed, as a replacement for array() dates to PHP 5.4,
but as a replacement for list() was only added in PHP 7.1.

I’m actually in favor of deprecating array() too, and I raised this
on the #php-internals Discord channel.

Are you crazy? That would invalidate at least three quarters of the WordPress core code base and almost all of it’s plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask.

That would almost certainly cause that community to either refuse to upgrade, leading to the problem the Python community faced with 2 & 3, or cause them to fork PHP.

To be clear, I find it ugly as Hell too, and I’d love to see the end of the @ error suppression operator, but there are things that simply cannot be done.

59

On Wed 1 Jul 2026, 20:35 Michael Morris, <tendoaki@gmail.com> wrote:

On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati azjezz@carthage.software wrote:

On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 29/06/2026 17:37, Seifeddine Gmati wrote:

Hello Internals,

I have updated the RFC to include a deprecation proposal for the
list() construct.

ref: https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_the_list_construct

I don’t think it makes sense to deprecate list() if we’re not
deprecating array() - they’re exact counterparts, and both replaced by
the syntax. Indeed, as a replacement for array() dates to PHP 5.4,
but as a replacement for list() was only added in PHP 7.1.

I’m actually in favor of deprecating array() too, and I raised this
on the #php-internals Discord channel.

Are you crazy? That would invalidate at least three quarters of the WordPress core code base and almost all of it’s plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask.

That would almost certainly cause that community to either refuse to upgrade, leading to the problem the Python community faced with 2 & 3, or cause them to fork PHP.

To be clear, I find it ugly as Hell too, and I’d love to see the end of the @ error suppression operator, but there are things that simply cannot be done.

That’s a very strong stance. It would invalidate a lot of old code but it’s a very simple change that can be done automatically. Most of the up-to-date code already switched to the new syntax so there is a trend in community’s code towards the new style. Deprecating array() would only speed it up.

We’re not talking here about deprecating arrays, just the old array() construct.

Deprecating list() is a little more challenging as not enough time has passed for old codebases to migrate to the new syntax but it also wouldn’t be world shattering as the change is very simple.

The benefit of this would be that we would be modernizing the language and removing two ways of doing the identical thing, which would be a very good thing for new users. No more confusion and messy code.

Compared to the error suppression operator or pass-by-ref, this is a very simple and unproblematic deprecation. We might want to delay the removal until PHP 10 but I see no reason to hold back on deprecation.

60

On Wed, 1 Jul 2026 at 19:36, Michael Morris <tendoaki@gmail.com> wrote:

On Mon, Jun 29, 2026 at 2:38 PM Seifeddine Gmati <azjezz@carthage.software> wrote:

On Mon, 29 Jun 2026 at 18:52, Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 29/06/2026 17:37, Seifeddine Gmati wrote:
> > Hello Internals,
> >
> > I have updated the RFC to include a deprecation proposal for the
> > `list()` construct.
> >
> > ref: PHP: rfc:deprecations_php_8_6
>
>
> I don't think it makes sense to deprecate list() if we're not
> deprecating array() - they're exact counterparts, and both replaced by
> the [] syntax. Indeed, [] as a replacement for array() dates to PHP 5.4,
> but as a replacement for list() was only added in PHP 7.1.

I'm actually in favor of deprecating `array()` too, and I raised this
on the #php-internals Discord channel.

Hi Michael,

Are you crazy?

Yes.

That would invalidate at least three quarters of the WordPress core code base and almost all of it's plugins, not to mention THOUSANDS of tutorials on stack overflow. And whether you like it or not about 40-60% of PHP sites use WordPress, depending on who you ask.

The migration is running a single command: `ast-grep -p
'array($$$ARGS)' -r '[$$$ARGS]' --lang php -U`

I dislike the idea that the langauge should not progress because
people genuinely don't want to take 2 minutes to upgrade their
codebase.

I don't think the WordPress team would have trouble replacing
`array()` with `[]` given that the minimum requirement for WordPress
is PHP 8.3. Older WordPress installations don't have to upgrade
because if they didn't bother upgrading WordPress, i doubt they will
bother upgrading PHP :slight_smile:

That would almost certainly cause that community to either refuse to upgrade, leading to the problem the Python community faced with 2 & 3, or cause them to fork PHP.

I don't think a single syntax change like `array($x)` to `[$x]` would
cause the Python 2 to Python 3 chaos here, given that the "modern"
syntax already works in older PHP versions.

Cheers,
Seifeddine.