Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107575
Message-ID: <EB4DF729-5C87-4FDC-BEE6-375D7886F4C1@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E5925F4A-B8D1-4AA9-9870-12C2294145D7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 18 Oct 2019 14:51:34 -0400
In-Reply-To: <CAEYWF=6_aa4CwcP_dBwbwvwWcP+zBqm3r0JP_FSTV6b2RsNJRw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Bishop Bettini <bishop@php.net>
References: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
 <CAEYWF=6_aa4CwcP_dBwbwvwWcP+zBqm3r0JP_FSTV6b2RsNJRw@mail.gmail.com>
Subject: Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_E5925F4A-B8D1-4AA9-9870-12C2294145D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Oct 17, 2019, at 11:14 PM, Bishop Bettini <bishop@php.net> wrote:
>=20
> +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] (*).
>=20
> That said, some questions:

Hi Bishop,

Thank you for the questions.

> Do you envision this token accepting an optional argument, as break =
does, to fall-through multiple nesting levels? Eg:

No.  I had not envisioned anything more than a single statement that =
would indicate to PHP and other tools that a developer intends to _not_ =
use a break.=20

What you suggest had not occurred to me, and is an interesting idea. But =
I think I would prefer =E2=80=94 like Rowan Tommins argued =E2=80=94 =
that we should keep it simple. =20

Being able to fallthrough many levels would be an extra feature we can =
already accomplish in other, more explicit ways. I would rather focus on =
targeting a use-case we cannot currently address, i.e. for PHP itself =
and other tools to be able to flag lack of an explicit case exiting =
action.


> What do you envision the result of indicating fall-through to no =
subsequent case? Eg:
>=20
> <?php
> switch ($x) {
> case 1: fallthrough;
> }
> ?>

Since it would have no effect that could be flagged or not flagged as a =
warning. =20

It might be nice to allow it so that refactoring is less likely to =
result in a warning.


> Would a "pragma" (of sorts) be a part of the concept?
>=20
> <?php declare(strict_break=3D1);
> switch ($x) {
> case 1: echo 'x1'; // ImplicitBreakError thrown here
> case 2: echo 'x2';
> }
> ?>

Yes, but recent discussions on this list lamented the concern that we =
could end up with tens if not hundreds of pragmas, and I concur that =
would be no fun. =20

So how we would indicate is an open question PHP should answer before =
adding a pragma for fallthrough. As an aside, I would be excited to see =
that discussion start in earnest.

Also, I am sure you remember that Nikita proposed an idea loosely =
described as "Editions" and that might be the way to go. Imagine the =
following:

<?php declare(edition=3D2020);
switch ($x) {
case 1: echo 'x1'; // ImplicitBreakError thrown here
case 2: echo 'x2';
}

Or another approach could just be version specific:

<?php declare(strict[version]=3Dphp8);
switch ($x) {
case 1: echo 'x1'; // ImplicitBreakError thrown here
case 2: echo 'x2';
}

For these though, the devil would be in the details.

-Mike=

--Apple-Mail=_E5925F4A-B8D1-4AA9-9870-12C2294145D7--