Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107568
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8EF53E35-D94C-452E-828F-DEA2EFE8C5D7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
Date: Thu, 17 Oct 2019 16:54:51 -0400
To: PHP Internals <internals@lists.php.net>
Subject: Adding explicit intent for SWITCH/CASE fall through?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_8EF53E35-D94C-452E-828F-DEA2EFE8C5D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi All,

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=20
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 =
warnings 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 =
this worthy of an RFC, or is there some reason a majority would object =
to such an addition?

Thanks in advance.

-Mike



--Apple-Mail=_8EF53E35-D94C-452E-828F-DEA2EFE8C5D7--