On 6-8-2025 6:21, Theodore Brown wrote:
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:
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
