Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107582
Message-ID: <1E765C07-5503-4A23-949D-F2D79E9C2164@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5364A955-1454-46E8-8AA0-D7AB4F52B5B5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 19 Oct 2019 20:39:38 -0400
In-Reply-To: <11ada3a9-ee9a-1364-7a06-96d1533d544b@alec.pl>
Cc: internals@lists.php.net
To: "A.L.E.C" <alec@alec.pl>
References: <929062F1-E83F-4D81-B2C6-3916B744E101@newclarity.net>
 <5da8e051.1c69fb81.b05ef.ef7dSMTPIN_ADDED_MISSING@mx.google.com>
 <D7C2364B-DA8F-4739-B18E-05D0A841872B@newclarity.net>
 <f40c7f3a-2ae7-8bb6-c2a6-aa8805fb9f01@fischer.name>
 <BD910368-A8B1-48F9-B6A7-C7F2D776E162@newclarity.net>
 <11ada3a9-ee9a-1364-7a06-96d1533d544b@alec.pl>
Subject: Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_5364A955-1454-46E8-8AA0-D7AB4F52B5B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 19, 2019, at 3:05 AM, A.L.E.C <alec@alec.pl> wrote:
> Imo, this would make more sense if fallthrough did something more, =
e.g. allowing
>=20
> case X:
> 	if (something) {
> 		fallthrough;
>        }
> 	something-else;
> 	break;
> case Y: ....

Interesting.=20

What would you expect this to do?  It is not intuitively obvious to me.


> Going this way we could imagine that `fallthrough N` could allow =
skipping N following
> `case`s

While I can see that as possible, I cannot think of any use-cases where =
I would even want to use it. Can you?

Either way, I doubt I would never use it as IMO it could make for some =
very fragile code. =20


> and `fallthrough default` jumping to the default section.

Now I do like this, because it does not seem fragile to me and I could =
see it having some use-cases.


> Then, don't we need a way to jump outside of the whole switch =
statement? Ah, there's `goto` already. So, maybe extend `goto` somehow?

Is that not what `break` is for?

> Adding a no-op keyword does not make much sense to me.

There are many no-op keywords already in PHP, such as typehints; they =
provide information to the PHP so it knows when to throw warnings and =
errors.

The fact a potential feature is a no-op does not discredit it for me; =
instead I focus on the benefits the proposed feature can provide.=20

In this case the benefits would be to alerting developer when they =
accidentally omit instructions to PHP of their intentions. And that =
seems to me to be something (almost?) everyone would want to see =
embraced?  Clearly* PHPStan and many Linux developers would like the =
same[1][2].


> It might be not useful enough to justify a BC break.=20

True, that is a concern.

Not yet having experience working on PHP's parser I do not know how it =
is configured nor what about the design of PHP requires keywords unable =
to be used as constants, class names, function or method names. I know =
this is a tangent but that seems like a requirement designed to simplify =
the parser maybe, and not because of any logical requirement. So I =
assume whatever word was used for this would also have to be a reserved =
keyword?  Or not?

Can someone who knows why the parser requires reserve words speak to =
why?=20

If it would have to be a BC break, then maybe we could overload break =
with `BREAK NEXT` instead of `FALLTHROUGH` to achieve the same goal?  Or =
`CONTINUE NEXT`?

I will say the term `FALLTHROUGH` is used in GoLang and the GCC =
compiler[2] so it might be the best for familiarity reasons, but BC =
might override that concern.

Does anyone know how to quickly scan the top PHP projects to see how =
many would break if `FALLTHROUGH` were used? I know I could write a =
program to do it, but I have so many other programs to write...

-Mike

* Props to Bishop Bettini for these links
[1] https://github.com/phan/phan/issues/2550 =
<https://github.com/phan/phan/issues/2550>
[2] https://lwn.net/Articles/794944/ <https://lwn.net/Articles/794944/>



--Apple-Mail=_5364A955-1454-46E8-8AA0-D7AB4F52B5B5--