Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121028
Date: Sun, 10 Sep 2023 11:38:12 +0100
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
In-Reply-To: <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
References: <CAPyj-LB16MUDNkgdQ7TrHpgNG2gD86H7+OP_g_rbuH0KYR9ZzQ@mail.gmail.com>
Message-ID: <F36BF563-A3A5-4C11-B11B-F2D87AD1FC40@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Draft] Match block
From: rowan.collins@gmail.com (Rowan Tommins)

On 8 September 2023 23:16:07 BST, Ilija Tovilo <tovilo=2Eilija@gmail=2Ecom>=
 wrote:
>Hello everyone
>
>I've been working on match blocks over the last few weeks=2E
>https://wiki=2Ephp=2Enet/rfc/match_blocks


Hi Ilija,

Thanks for working on this=2E A few initial thoughts=2E=2E=2E


The use of "<-" as the new token doesn't fit the language very well=2E The=
 "family" it belongs to are all keywords not symbols: return, yield, throw,=
 break, continue=2E I understand that you don't want to reuse one of those,=
 but presume a new keyword would not need to be fully reserved?

Relatedly, I note that in the RFC text, you've talked about the arms "retu=
rning" a value, but also made clear that a return statement is also allowed=
=2E I think it would be clearer to pick a term other than "return" for what=
 this token does, and use it consistently=2E

My suggestion to start the ball rolling is "resolve" - that is, "The block=
 resolves to a value given after the 'resolve' keyword=2E"


Having said all that, the ability to put control flow like return and yiel=
d into match statements feels a little weird to me=2E Again, it's partly th=
e syntax - the "=3D>" is reminiscent of array literals and short lambdas, w=
hich are very much expressions not statements=2E

You say in the introduction that part of the motivation is to more complet=
ely replace "switch", but I wonder if that would be better solved with a di=
fferent construct that handles the non-expression-like uses of switch=2E In=
 particular, although fall-through by default (if "break" is not specified)=
 is definitely a historic mistake, the *ability* to fall through to another=
 case is sometimes useful, so those cases would still not be convertible to=
 "match"=2E

A "strict switch" could look more like the current control flow structures=
, but add strict equality (and pattern matching in future) and remove impli=
cit fall-through, without having to squeeze into the same syntax as match e=
xpressions=2E


My final thought for now is a short and slightly off-topic one: someone re=
ally needs to look into adding opt-in block scoping to PHP, similar to JS "=
let"=2E It would fit so well with proposals like this one!


Regards,

--=20
Rowan Tommins
[IMSoP]