Re: [RFC][Draft] Match block
| From: | Rowan Tommins | Date: | Sun, 10 Sep 2023 10:38:12 +0000 |
| Subject: | Re: [RFC][Draft] Match block | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121028@lists.php.net to get a copy of this message | ||
On 8 September 2023 23:16:07 BST, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>Hello everyone
>
>I've been working on match blocks over the last few weeks.
>https://wiki.php.net/rfc/match_blocks
Hi Ilija,
Thanks for working on this. A few initial thoughts...
The use of "<-" as the new token doesn't fit the language very well. The
"family" it belongs to are all keywords not symbols: return, yield, throw, break,
continue. 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 "returning" a
value, but also made clear that a return statement is also allowed. I think it would be clearer to
pick a term other than "return" for what this token does, and use it consistently.
My suggestion to start the ball rolling is "resolve" - that is, "The block resolves
to a value given after the 'resolve' keyword."
Having said all that, the ability to put control flow like return and yield into match statements
feels a little weird to me. Again, it's partly the syntax - the "=>" is
reminiscent of array literals and short lambdas, which are very much expressions not statements.
You say in the introduction that part of the motivation is to more completely replace
"switch", but I wonder if that would be better solved with a different construct that
handles the non-expression-like uses of switch. 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".
A "strict switch" could look more like the current control flow structures, but add strict
equality (and pattern matching in future) and remove implicit fall-through, without having to
squeeze into the same syntax as match expressions.
My final thought for now is a short and slightly off-topic one: someone really needs to look into
adding opt-in block scoping to PHP, similar to JS "let". It would fit so well with
proposals like this one!
Regards,
--
Rowan Tommins
[IMSoP]