Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128414
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: Theodore Brown <theodorejb@outlook.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
 <68830C4F.5020107@adviesenzo.nl>
 <BL4P223MB1364F71BAB2313DCE68882AADE2DA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM>
Message-ID: <6893E062.2070709@adviesenzo.nl>
Date: Thu, 7 Aug 2025 01:08:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <BL4P223MB1364F71BAB2313DCE68882AADE2DA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative;
 boundary="------------070804010002030800000102"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------070804010002030800000102
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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




--------------070804010002030800000102
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 6-8-2025 6:21, Theodore Brown wrote:<br>
    <blockquote
cite="mid:BL4P223MB1364F71BAB2313DCE68882AADE2DA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM"
      type="cite">
      <pre wrap="">On Thu, July 24, 2025 at 22:47 Juliette Folmer wrote:

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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:

<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/deprecations_php_8_5">https://wiki.php.net/rfc/deprecations_php_8_5</a>
</pre>
        </blockquote>
        <pre wrap="">

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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    Hi Theodore,<br>
    <br>
    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.<br>
    <br>
    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.<br>
    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.<br>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:BL4P223MB1364F71BAB2313DCE68882AADE2DA@BL4P223MB1364.NAMP223.PROD.OUTLOOK.COM"
      type="cite"><br>
      <blockquote type="cite">
        <pre wrap="">== 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).
</pre>
      </blockquote>
      <pre wrap="">
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.
</pre>
    </blockquote>
    <br>
    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.<br>
    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.<br>
    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.<br>
    It also means more detection tooling needs to be created - like in
    PHPCompatibility - to detect this for years to come.<br>
    <br>
    So no, in my estimation, deprecating this syntax will create more
    work, not less work for code style fixing libraries and adjacent
    projects.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------070804010002030800000102--