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

Mailing Lists php.internals
61

Hello internals,

As Tim announced a few days ago, I've opened the votes for the deprecations:

Please remember that the wiki is only capable to handle a single vote at a time,
so please submit each vote you intend on casting individually.

Best regards,

Gina P. Banyard

62

Thank you for compiling the list, managing the process, and building in process improvements like ensuring every vote has a deprecation message attached.

It’s very much appreciated how structured, well researched, and explained things are!

And while adding my takes now, after weeks of discussion already taking place, feels improper, but I’m excited to see the results and am looking forward to voting and wanted to thank you for helping to clean up the lanuage and allowing us to move forward.

Kind Regards,
Volker

···

Volker Dusch
Head of Engineering

Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint

Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127

63

On Jul 25, 2025, at 9:40 AM, Gina P. Banyard <internals@gpb.moe> wrote:

Hello internals,

As Tim announced a few days ago, I've opened the votes for the deprecations:
PHP: rfc:deprecations_php_8_5

Heads up, I've adjusted the header name for the driver specific build
flags to change deprecate to remove, matching the body of the proposal.
I suspect it probably won't change people's opinions on the matter, but
I'd like to be clear. I have not changed the vote names since I don't
know if that will break the existing polls. The body remains the same.

Thanks to Daniel for pointing this out.

64

On 29 July 2025 17:23:40 BST, Calvin Buckley <calvin@cmpct.info> wrote:

I have not changed the vote names since I don't
know if that will break the existing polls.

I can confirm that that would have broken it.

cheers
Derick

65

On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:

On Mon, Jul 14, 2025, at 5:36 AM, Derick Rethans wrote:
> On Thu, 3 Jul 2025, Jakub Zelenka wrote:
>
>> On Wed, Jul 2, 2025 at 10:00 PM Gina P. Banyard <internals@gpb.moe> wrote:
>>
>> > It is this time of year again where we proposed a list of
>> > deprecations to add in PHP 8.5:
>> >
>> > PHP: rfc:deprecations_php_8_5
>>
>> Here are few notes on the ones that I don't agree with:
>>
>> > Deprecate backticks as an alias for shell_exec
>>
>> I think this might be too big BC break that might impact many scripts
>> - would be good to see also if it impacts OSS projects. I guess it
>> will impact even more non public code bases.
>
> Indeed, I use this *all the time* in quick hacky shell scripts in PHP.
> Best practise? Definitely not. But it certainly is very useful.

Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)

--Larry Garfield

This sounds quite negative to me which it is not in my book, IMHO best to have all three available in PHP, so you would have made the argument for me to keep the symbol.

And thinking:

Symbol reuse could perhaps be possible already today with a prefix.

The backticks operator evaluates to a string (or a primitive that could be represented as a string), which is an interface to build upon. For example a "tagging"-function:

    $result = shell`git describe --abbrev=0 --match=dev* --tags dev$ver^`;

    function shell($what, ...$not)
    : on_return_this_type_is_checked_by_the_script_interpreter
    {
        (random_int(0, 1))
        and throw new Error('To Return Never when it's due');
        
        return rtrim(shell_exec(something_with($what, 'and', $not)));
    }

This could also improve the current use, even immediately, and eventually helps to think out of the box.

    $name = 'PHP-Parser';
    $version = '5.5.0';
    $hash = 'sha384-vyGSwY5XXGRpPplN6utmy1kOiFBeqy79G0BRG8CnfT8AvHx7TBb99HFHkUEcXSs3';

    $res = cas`https://github.com/nikic/\{$name\}/archive/v\{$version\}\.tar\.gz\#sri=\{$hash\}\#\`;

String is the universal interface.

My educated guess is that I don't need to explain the benefits of _template literals_ over ordinary PHP string literals for Larry, but for those who are curious, this is inspired by EcmaScript and you can try it out in your browser or read on MDN about it. Not saying this should be the same syntax, just going into the pink here. Maybe even recent ${'...'} vs. "{${'...'}}" changes in interpolation opened up some room to come closer.

Now if only those backticks would become an aspect of the tag over the assignment so we could get "get hook semantics" on them at the time of tagged-use:

  $untagged = `....`;
  $result1 = tagRed$untagged;
  $result2 = tagBlue$untagged;

hmm... not entirely compatible with the current behaviour I'd guess, but who knows, likely conflicts over conflicts in the LALR parser when we start to tag $variable identifiers.

Just my 2 cents.

-- hakre

66

On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:

On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:

Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)

--Larry Garfield

*snip*

My educated guess is that I don't need to explain the benefits of
_template literals_ over ordinary PHP string literals for Larry, but
for those who are curious, this is inspired by EcmaScript and you can
try it out in your browser or read on MDN about it.

Indeed, that's the sort of future reuse I was thinking of as well. But having this be a template:

$foo = tpl`Something $here`;

But this run a shell command:

$foo = `Something $here`;

Strikes me as a security nightmare waiting to happen.

--Larry Garfield

67

On Thu, July 24, 2025 at 22:47 Juliette Folmer wrote:

On 2-7-2025 21:56, G. P. Banyard wrote:

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

PHP: rfc:deprecations_php_8_5

Just leaving a note here that I find it inconceivable that the fast majority of proposed
deprecation (again) do NOT have an impact analysis.

I've spoken up about this before and will continue to do this as it basically means
a "blind vote", where voters can only rely on their own experience to gauge the impact
and I expect the majority of voters to predominantly work on code which already follows
a lot of best practices, which skews the vote towards deprecation, disregarding the real
world impact on less clean codebases.

Hi Juliette,

I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:

## Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.

## Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.

I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.

== Deprecate semicolon after case in switch statement ==

Opinion: Feels like an unnecessary deprecation.

Side-note: The deprecation is also already flagged by PHPCS and will be auto-fixable
as of PHP_CodeSniffer 3.13.3 (via the PSR2.ControlStructures.SwitchDeclaration sniff).

Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:

1. It requires projects and coding style guides to choose and document which syntax to use.
2. Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes.
3. Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.

Kind regards,
Theodore

68

On 06.08.2025 at 06:21, Theodore Brown wrote:

I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:

## Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.

## Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.

I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.

I would not necessarily expect backtick operators to be used in top
Composer packages. That is likely a feature used by some private shell
scripts; maybe sometimes quick and dirty through-away/ use-once scripts.

Christoph

69

On Wed, August 6, 2025 at 03:09 Christoph M. Becker wrote:

On 06.08.2025 at 06:21, Theodore Brown wrote:

I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:

## Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.

## Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.

I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.

I would not necessarily expect backtick operators to be used in top
Composer packages. That is likely a feature used by some private shell
scripts; maybe sometimes quick and dirty through-away/ use-once scripts.

Hi Christoph,

Here's the list of usages:

Some appear to be in tests or internal scripts, but not all.
E.g. the laravel\pulse usages, and the ones for console utilities.

Theodore

70 



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

[https://wiki.php.net/rfc/deprecations_php_8_5](https://wiki.php.net/rfc/deprecations_php_8_5)


Just leaving a note here that I find it inconceivable that the fast majority of proposed
deprecation (again) do NOT have an impact analysis.

I've spoken up about this before and will continue to do this as it basically means
a "blind vote", where voters can only rely on their own experience to gauge the impact
and I expect the majority of voters to predominantly work on code which already follows
a lot of best practices, which skews the vote towards deprecation, disregarding the real
world impact on less clean codebases.


I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:

## Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.

## Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.

I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.

Hi Theodore,

Thank you for making the effort to gather more impact analysis. I wish this kind of information would be mandatory for all deprecations and I appreciate your efforts to help gather the info, though considering the timing, it probably won’t have any impact on the vote anymore.

I’m not surprised at all by the 0 usage of the semicolon-terminated case statements in the top 1500 packages as it is forbidden by PSR2 and a significant number of the top 1500 packages use PSR2/12/PER.
In contrast, PSR2/12/PER does not have any rules about the use of non-standard cast names or the use of the backtick operator.

I also imagine if impact analysis would be done on, let’s say package 20.000 to 22.000, instead of the top 1500 (or on both), results may be interestingly different.

== Deprecate semicolon after case in switch statement ==

Opinion: Feels like an unnecessary deprecation.

Side-note: The deprecation is also already flagged by PHPCS and will be auto-fixable
as of PHP_CodeSniffer 3.13.3 (via the PSR2.ControlStructures.SwitchDeclaration sniff).


Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:

1. It requires projects and coding style guides to choose and document which syntax to use.
2. Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes.
3. Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.

I don’t think this reasoning is valid. Code style tools which have support for scanning code against PSR2 already handle this and have for a long time. There is no significant maintenance costs to that anymore. The costs is in the past.
More than anything, even when the syntax would be deprecated and eventually removed, these tools will still need to keep up support for flagging these things as these tools are often enough used on older code bases, which haven’t been updated for the deprecation yet.
The deprecation and eventual removal will more likely increase maintenance costs for these tools, as contributors less versed in the intricacies of PHP will try to remove support or flag the test code used as a parse error, which then means a maintainer will have to explain this used to be supported by PHP etc etc.
It also means more detection tooling needs to be created - like in PHPCompatibility - to detect this for years to come.

So no, in my estimation, deprecating this syntax will create more work, not less work for code style fixing libraries and adjacent projects.

Smile,
Juliette

71

On Wed, August 6, 2025 at 17:08 Juliette Reinders Folmer wrote:

On 6-8-2025 6:21, Theodore Brown wrote:

I just analyzed the top 1500 Composer packages for a couple more of the proposed syntax
deprecations, and found the following:

## Deprecate non-standard cast names:
197 non-standard casts in 25 unique packages.

## Deprecate backticks as an alias for shell_exec:
49 backtick operator executions in 10 unique packages.

I find it ironic that the more widely used of these proposals has the least opposition to
deprecate (100% in favor so far), while deprecating semicolon-terminated case statements
(which has zero usages in the top 1500 packages) currently has more opposition than either
of these.

Hi Theodore,

Thank you for making the effort to gather more impact analysis. I wish this kind of
information would be mandatory for all deprecations and I appreciate your efforts to
help gather the info, though considering the timing, it probably won't have any impact
on the vote anymore.

Hi Juliette,

You are welcome. It takes time to download top packages and write analysis scripts,
which is probably why it hasn't been done for more of the deprecation proposals.
I agree that it's generally nice to have impact data, though.

I'm not surprised at all by the 0 usage of the semicolon-terminated case statements
in the top 1500 packages as it is forbidden by PSR2 and a significant number of the
top 1500 packages use PSR2/12/PER.
In contrast, PSR2/12/PER does not have any rules about the use of non-standard cast
names or the use of the backtick operator.

This is not the case. Since PSR-12 the longer type keywords have been forbidden.
See PSR-12: Extended Coding Style - PHP-FIG, which states:

"Short form of type keywords MUST be used i.e. `bool` instead of `boolean`,
`int` instead of `integer` etc."

Perhaps the deprecation seems unnecessary at first, but there is a non-zero cost to
maintaining this legacy alternate syntax in the language:

1. It requires projects and coding style guides to choose and document which syntax to use.
2. Coding style fixers like PHP-CS-Fixer and PHPCS have to implement and maintain fixers
to enforce one of the syntaxes.
3. Who knows whether the alternate syntax may block future proposals, as was the case for
the curly brace array/string offset syntax, which being deprecated in PHP 7.4 made it
possible to implement property hooks in PHP 8.4.

I don't think this reasoning is valid. Code style tools which have support for scanning
code against PSR2 already handle this and have for a long time. There is no significant
maintenance costs to that anymore. The costs is in the past.

More than anything, even when the syntax would be deprecated and eventually removed,
these tools will still need to keep up support for flagging these things as these
tools are often enough used on older code bases, which haven't been updated for the
deprecation yet.

The deprecation and eventual removal will more likely increase maintenance costs for
these tools, as contributors less versed in the intricacies of PHP will try to remove
support or flag the test code used as a parse error, which then means a maintainer
will have to explain this used to be supported by PHP etc etc.

It also means more detection tooling needs to be created - like in PHPCompatibility -
to detect this for years to come.

So no, in my estimation, deprecating this syntax will create more work, not less
work for code style fixing libraries and adjacent projects.

Even if there is some short term effort to automate deprecation detection and fixes,
these tools will eventually drop support for PHP 8.x, at which point it will no longer
be necessary to maintain the fixers. Without the deprecation, there is extra work
indefinitely to ensure the fixers continue to work with the syntax in new PHP versions.

And tooling maintenance is not the only cost. One of the reasons I was motivated to
include the deprecation proposal was seeing all the discussions over the years in
Drupal related to this. See https://www.drupal.org/project/coding_standards/issues/2999367
(starts in 2018) and the referenced issues.

Deprecating this unnecessary legacy syntax will eventually remove the need to
maintain extra tooling and coding style documentation, and ultimately
eliminate a source of confusion and inconsistency in the language.

Sincerely,
Theodore

72

On Friday 04 July 2025 14:40:23 (+02:00), Tim Düsterhus wrote:

Hi

On 7/3/25 18:04, Derick Rethans wrote:
> The intention behind the filter extension was that admins can set a
> default filter for *all* data coming in through this `filter.default`
> setting as a "safe" fallback. That could/should probably even be a

Genuine question: Is that *intention* documented anywhere? PHP: filter_input - Manual only makes factual statements about the behavior, but not how one is supposed to use them. Similarly PHP: Runtime Configuration - Manual also says that a default filter can be configured, but not why one would want to do so.

If we look into php-src docs, nowadays under the docs-old entry IIRC, we may find how to write a filter.

That it is on the level of extending PHP, and I'd interpret that it strongly points towards system administration or at least that it is about making systematic use of the PHP filter extension.

Have not yet made research based on age or reviewed specifically after your message, e.g. correlations towards the date since ext.filter is part of the solution, but my nose tells me the documentation is likely related to what you'd like learn more about.

This may be totally misleading, but when I combine that with Derricks expertise in php-src and his earlier comment, I'm somehow under the impression this has the potential to answer even genuine questions that require to reason about documented intend.

So please let me know if it is still of help @Tim

-- hakre

73

On Tuesday 29 July 2025 21:43:39 (+02:00), Larry Garfield wrote:

> On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:
> > On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
> > >> Is their use for quick hacky scripts worth the cost of reserving a symbol that could be repurposed for something else more generally useful in the future? (Not immediately of course, but eventually.)
> >> > >> --Larry Garfield
> > *snip*
> > > My educated guess is that I don't need to explain the benefits of > > _template literals_ over ordinary PHP string literals for Larry, but > > for those who are curious, this is inspired by EcmaScript and you can > > try it out in your browser or read on MDN about it. > > Indeed, that's the sort of future reuse I was thinking of as well.

Yes, I have hoped, so good to read!

Do you know by chance this has gotten some movement towards that form of reuse in the past? I'd be interested.

> But having this be a template:
> > $foo = tpl`Something $here`;
> > But this run a shell command:
> > $foo = `Something $here`;
> > Strikes me as a security nightmare waiting to happen.

Oh, that was not intended. I need your precise eyes for this, and starring fearfully at the snakes is certainly not good for that. Sorry!

That suggestion is the migration form. Naturally, this needs to be properly packaged, you can't tell users that template literals are there and leave them in the un-tagged form as command substitution. Who would do that seriously?

Users of command substitution would have the opportunity to convert their backticks into a predefined, tag-limited form of a template literal. That is fool-proof, and it can't be conflated.

Therefore, there is no unguarded use of command substitution, this is inserting into the transition for existing users that are using backticks as they already do today.

My thought in the margin was that of a birthday present for the 25th of the backticks and users of the language (the global 50th is in 2029.)

Best

-- hakre