Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107571
MIME-Version: 1.0
References: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
In-Reply-To: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
Reply-To: bishop@php.net
Date: Thu, 17 Oct 2019 23:14:09 -0400
Message-ID: <CAEYWF=6_aa4CwcP_dBwbwvwWcP+zBqm3r0JP_FSTV6b2RsNJRw@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000be974a059526bb1d"
Subject: Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?
From: bishop@php.net (Bishop Bettini)

--000000000000be974a059526bb1d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 17, 2019 at 4:54 PM Mike Schinkel <mike@newclarity.net> wrote:

> Before creating an RFC I wanted to get reactions to the idea of adding
> FALLTHROUGH option to SWITCH/CASE for when the developer explicitly want
> logic to fall through to the next case and does not want to use a BREAK.
>
> My simples motivation for this feature is that my IDE (PhpStorm) always
> flags CASE statements w/o BREAKs because it cannot know when I intend for
> the logic to fallthrough and not break.  If there was an optional
> FALLTHROUGH then my IDE could flag any CASE statements that do not have a
> FALLTHROUGH or BREAK =E2=80=94 which would indicate an error of my intent=
 =E2=80=94 and
> avoid flagging all the situations where I intentionally want it to fall
> through.
>
> Beyond that, this might also be useful for other static analysis tools
> such as PhpStan.
> Ust
> Additionally it could be added in 8.0 and then in 8.1 flagged with a
> warning when a CASE does not have one for the two, but only if people don=
't
> object to this. While I know some on this list feel strongly that warning=
s
> must come with to future plans to generate errors I would personally be
> 100% okay if it indefinitely generated only a warning.
>
> In summary I want a mechanism to be allow me to explicitly indicate my
> intent with respect to SELECT/CASE statements.  What do you think? Is thi=
s
> worthy of an RFC, or is there some reason a majority would object to such
> an addition?
>

+1. It's 100% opt-in. People can keep using implicit fall-through, their
own /* fallthrough */ comments, or the new token. There's virtually no
overhead in the compile phase and it doesn't mess with the jump table
optimizations. There's precedent for this desire in PHP static analyzers
[1] as well as other major projects: eg, the Linux Foundation just
completed a 2 year project to remove implicit fall-through in the Linux
kernel [2] (*).

That said, some questions:

Do you envision this token accepting an optional argument, as break does,
to fall-through multiple nesting levels? Eg:

<?php
$x =3D $y =3D $z =3D 1;
switch ($x) {
case 1:
    switch ($y) {
    case 1:
        switch ($z) {
        case 1: fallthrough 3;
        case 2: echo 'z2';
        }
    }
    break;
case 2: echo 'x2'; break;
}
?>

What do you envision the result of indicating fall-through to no subsequent
case? Eg:

<?php
switch ($x) {
case 1: fallthrough;
}
?>

Would a "pragma" (of sorts) be a part of the concept?

<?php declare(strict_break=3D1);
switch ($x) {
case 1: echo 'x1'; // ImplicitBreakError thrown here
case 2: echo 'x2';
}
?>

[1]:https://github.com/phan/phan/issues/2550
[2]:https://lwn.net/Articles/794944/

(*) Fun trivia: PHP is mentioned in that LWN article about naming
conventions.

--000000000000be974a059526bb1d--