Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128839
To: PHP internals <internals@lists.php.net>,
 Theodore Brown <theodorejb@outlook.com>
Subject: [PHP-DEV] Inconsistency in PHP 8.5 deprecation of terminating case with semicolon
Message-ID: <68EEE5F4.5070105@adviesenzo.nl>
Date: Wed, 15 Oct 2025 02:08:20 +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
Content-Type: multipart/alternative;
 boundary="------------050601050801020701080401"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------050601050801020701080401
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear Theodore and list,

I've been looking into the "Deprecate semicolon after case in switch 
statement" PHP 8.5 deprecation [1] with the aim of adding a sniff for 
this to the PHPCompatibility standard and I'm noticing an oddity for 
which I would like to clarify whether this is intentional or an oversight.

As demonstrated in the example code provided in the deprecation RFC, 
both switch `case` condition statements, as well as `default` 
statements, can be ended with a semicolon.

So when I first read the RFC, I interpreted the proposal to include both 
`case` as well as `default`, as, in my mind, `default` is just a special 
`case` in a switch.

However, the RFC explicitly only talked about deprecating the use of a 
semicolon after a `case` statement and the implementation has followed 
this to the letter. [2]

The net result of this, is that you can now have a `switch` statement 
with semicolons terminating `case` statements and `default` statements, 
where the former (`case`) will result in a deprecation notice, while the 
latter (`default`) will not. For an example, see [3]

This feels inconsistent to me and counter to the intention of the RFC, 
which is stated to be:

 > Case statements followed by a semicolon can cause confusion, as a 
developer may think they behave differently in some way from regular 
case statements (e.g. preventing fallthrough), when they do not.

Which leaves me wondering what the reason was not to _also_ deprecate 
the use of a semicolon to terminate a `default` statement in a switch ?
I can't find any discussion about this in the original mailing list 
thread [4].

Anyone would care to clarify ?

Smile,
Juliette

1: 
https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_semicolon_after_case_in_switch_statement
2: 
https://github.com/php/php-src/commit/5f8d648af6ef4e29a3c7f2b2029d08466c12bc6f
3: https://3v4l.org/liFIK/rfc#vgit.master
4: https://externals.io/message/126000

--------------050601050801020701080401
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="-1"><font face="Verdana">Dear Theodore and list,<br>
        <br>
        I've been looking into the "Deprecate semicolon after case in
        switch statement" PHP 8.5 deprecation [1] with the aim of adding
        a sniff for this to the PHPCompatibility standard and I'm
        noticing an oddity for which I would like to clarify whether
        this is intentional or an oversight.<br>
        <br>
        As demonstrated in the example code provided in the deprecation
        RFC, both switch `case` condition statements, as well as
        `default` statements, can be ended with a semicolon.<br>
        <br>
        So when I first read the RFC, I interpreted the proposal to
        include both `case` as well as `default`, as, in my mind,
        `default` is just a special `case` in a switch.<br>
        <br>
      </font></font><font size="-1"><font face="Verdana"><font size="-1"><font
            face="Verdana">However, the RFC explicitly only talked about
            deprecating the use of a semicolon after a `case` statement
            and the implementation has followed this to the letter. [2]<br>
          </font></font><br>
        The net result of this, is that you can now have a `switch`
        statement with semicolons terminating `case` statements and
        `default` statements, where the former (`case`) will result in a
        deprecation notice, while the latter (`default`) will not. For
        an example, see [3]<br>
        <br>
        This feels inconsistent to me and counter to the intention of
        the RFC, which is stated to be:<br>
        <br>
        &gt; </font></font><font size="-1"><font face="Verdana">Case
        statements followed by a semicolon can cause confusion, as a
        developer may think they behave differently in some way from
        regular case statements (e.g. preventing fallthrough), when they
        do not.
        <br>
        <br>
        Which leaves me wondering what the reason was not to _also_
        deprecate the use of a semicolon to terminate a `default`
        statement in a switch ?<br>
        I can't find any discussion about this in the original mailing
        list thread [4].<br>
        <br>
        Anyone would care to clarify ?<br>
        <br>
        Smile,<br>
        Juliette<br>
        <br>
        1:
<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_semicolon_after_case_in_switch_statement">https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_semicolon_after_case_in_switch_statement</a><br>
        2:
<a class="moz-txt-link-freetext" href="https://github.com/php/php-src/commit/5f8d648af6ef4e29a3c7f2b2029d08466c12bc6f">https://github.com/php/php-src/commit/5f8d648af6ef4e29a3c7f2b2029d08466c12bc6f</a><br>
        3: <a class="moz-txt-link-freetext" href="https://3v4l.org/liFIK/rfc#vgit.master">https://3v4l.org/liFIK/rfc#vgit.master</a><br>
        4: <a class="moz-txt-link-freetext" href="https://externals.io/message/126000">https://externals.io/message/126000</a><br>
      </font></font>
  </body>
</html>

--------------050601050801020701080401--