On Fri, Sep 8, 2023 at 7:16 PM Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Hello everyone > > I've been working on match blocks over the last few weeks. > https://wiki.php.net/rfc/match_blocks > > I've already shared it in R11 and got conflicting feedback, which > makes me unsure on how to proceed. We have a few options. > > 1. Add blocks only to match, possibly adding blocks to other > constructs in separate RFCs (the approach of this RFC) > 2. Support block expressions as a language-level concept, analogous to > https://doc.rust-lang.org/reference/expressions/block-expr.html > 3. Do nothing > > The two main complaints/questions I've gotten was whether this > approach is the right one, and whether the syntax can be improved. The > RFC tries to go into detail on explaining the rationale for the chosen > approach. Additionally, it proposes a few alternate syntax options, > although none of them are very satisfactory. > > At this point I'm unsure whether a proposal can satisfy all camps. Let > me know if you have any thoughts/ideas. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hi Ilija, This seems like an interesting subject for the PHP language, but unfortunately doesn't take the direction I would much have preferred. The use of `<-` to denote a different style of return statement in a block feels quite "alien" (for lack of a better word) in the language for me. In addition to that, I'm also not sure if there's anything else in PHP that behaves differently when a return value is expected or not - this is in relation to the difference between `$result = match()` vs `match()` without expecting a result. If there's anything else in PHP that already has a similar behavior, it might be worth adding it to the RFC so that we can relate the subjects. To me it would be much better to stick with the existing language constructs just as-is. ``` <?php var_dump(match ('foo') { 'foo' => { echo "foo branch reached\n"; }, }); // foo branch reached // NULL var_dump(match ('foo') { 'foo' => { echo "foo branch reached\n"; return 'this will be dumped'; }, }); // foo branch reached // string(19) "this will be dumped var_dump(fn () => { echo "auto-capturing short closure invoked\n"; }()); // auto-capturing short closure invoked // NULL var_dump(fn () => { return 'foo'; }()); // string(3) "foo" $foo ??= { bar(); }; var_dump($foo); // NULL $foo ??= { bar(); return 'baz'; }; var_dump($foo); // string(3) "baz" ``` There's a somewhat related discussion on this RFC https://wiki.php.net/rfc/auto-capture-closure#multi-line_expressions which comes to mind and was just 2 votes short of have been approved. Other good-related RFCs are https://wiki.php.net/rfc/short-match and https://wiki.php.net/rfc/short-functions which creates a really nice symmetry in the language syntax. Ultimately, this is a sad 10-year-long discussion (as summarised here: https://externals.io/message/113740#113833) that seems impossible to move forward within the PHP language. The door of creating of a block with auto-capture look-and-feel much better across many different aspects of the language, but it's always shutdown by enough long-time voters. Overall, between the choice of creating a new syntax that "kind of represents return statements on specific scenarios" or option 3 - do nothing, I would prefer to do nothing until we manage to gather enough voters to overcome the "no-auto-capture" camp. -- Marco Deleu
