Hi Ilija, On Sun, Apr 12, 2020 at 2:16 AM Ilija Tovilo <tovilo.il...@gmail.com> wrote: > > I'd like to announce the match expression RFC that replaces the switch > expression RFC I announced a few weeks ago. > New: https://wiki.php.net/rfc/match_expression > Old: https://wiki.php.net/rfc/switch_expression
I know I'm a little late to the game and sorry for that, but I didn't have time to thoroughly read the proposal earlier. And again, sorry if it's just me going "blind" but I can't find anything explaining what will happen if there is more than one matching arm? I imagine that since the case of no matching arms will throw an UnhandledMatchError exception, having several matching arms will also complain that something looks wrong? However, that will require all the arms to be evaluated every time, even after a match is found, which might not be the most optimal approach. Then again, if not all arms might be evaluated, the order of evaluation is important (since several matching arms could be found), but it's not stated in the RFC if the order of evaluating arms follows the order they are written, or if the compiler/interpreter is allowed to choose another order if it thinks it might find the matching arm sooner? --- To recap, perhaps you can answer these questions clearly in the RFC: - What happens if more than one arm is matching? - In which order are the arms evaluated (in case order is significant) - is it predictable or an implementation detail that the developer should not rely on? - Can the left side of the arms be any expression or only "constant-style"? (If expressions are allowed, order also becomes significant) Apart from these questions, it might be a good idea to evaluate the impact of the Backwards Incompatible Changes by checking top repositories for the use of the new keyword "match" in classes and namespaces etc. Finally, I find the mixing of match as expression and match as stand-alone statement unfortunate. I understand very well the closeness between the two, but I also think that those are two quite different use-cases which presume different intentions and expectations for behavior: For example, when using "match" as an expression and assigning the value to a variable (the second example at the top of the RFC - as an alternative to hash maps and nested ternary operators) it's natural to assume that one and exactly one arm must match. Otherwise the variable will end up with an ambiguous or undefined value. I also would consider it "flippant" and not a common need to use block statements as the arms in this case! On the contrary, when using "match" as a statement (much more like "switch" and like "if"), there is no problem if no arms match, and if several arms match, why not execute all of them? Also, block statements in the arms would be natural and common. Would it be a possibility to separate the two into different RFC's? Personally I find the expression style most useful and I'd be happy to see this part passed, which I think would be relatively easy since a lot of the more complex points could be evaded: Block statements, return statements, break/continue statements (which I don't really understand in the context of an expression) and the trailing semicolon issue. Hope the feedback was useful and best of luck with the RFC! Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
