I've been unable to find a discussion on the following subject. I think structural pattern matching could sometimes be more useful to be available to form an expression than to form a statement. To be specific, given the definition of a function of the form ``` def f(): match <expression>: case <pattern 1> if <condition 1>: return <expression 1> case <pattern 2> if <condition 2>: return <expression 2> case ... ...... ``` I imagine something like ``` (<expression 1>) if <condition 1> case <pattern 1>\ else <expression 2> if <condition 2> case <pattern 2>\ else ... ...... else <expression last> case _ match (<expression>) ``` as an expression such that it preceded by "lambda : " would specify an equivalent function. This of course doesn't fully characterize the expression, which could be evaluated not just in the scope of the function. To in terms of the two functions, they could be equivalent including how the local namespace is modified. (You might look at a few remarks on the syntax at the bottom.) What may it be good for? Such an expression is analogous to a conditional expression. ``` *** if ... else *** if ... else *** ``` An if-statement gives you a list of statements for each case, but a conditional expression gives an expression for each case. You'd more like the latter at some places (while more the former at some other places). The similar thing can be thought of about structural pattern matching. On the other hand, a match statement can be more preferable than an equivalent if-statement in some cases, so I think there can be something more preferable than a conditional expression in similar cases. Here's a picture of the idea. if-statement ======> conditional expression | | | | V V match statement ===> Do we want something here? I expect some expressions using structural pattern matching would be less repetitive to write and easier to read than equivalent conditional expressions. Comparison would be similar to that of match statements with if-statements. Remark ------ A larger theme may be a kind of expression associated to any kind of compound statement. Note the form of function like f above can be considered with any kind of compound statement. Namely, one can consider a function whose code is a compound statement of the considered kind with every suite a return statement, or perhaps better, of the form yield <expression>. One may then wish for an "expression version" of it like considred above for the case of match statement. Another example of existing such thing than conditional expression is comprehension, essentially corresponding to for-statement (where the dict comprehension is a slight extension of it). Similary, one may consider comprehension corresponding to a while-loop instead of a for-loop. for-loop comprehension can also be done with the functions map (and filter). One can consider a similar function map_while (or "apply_while"?) for while-comprehension. Another thing about comprehension is that the form of the model function f can very meaningfully be modified so the suite is to be of the form yield from <expression>. I've seen a proposal of syntax for the corresponding comprehension. An expression analogue of match statement seems to be a good place to start from (whether the larger theme may go anywhere). Remarks on the syntax --------------------- (1) "if <condition i>" can be omitted where no guard is necessary. (2) I expect the last case in the expression not being the wildcard pattern "_" without a guard would result in SyntaxError raised. (<expression last> can be None if the match statement in the original definition of the function doesn't have this case.) (3) Parentheses around <expression 1> and <expression> in the expression are in case those expressions are themselves conditional or similarly formed with structural pattern matching (let me call an expression of the form a match expression for short). Actual necessity of parentheses in these and other places (such as around a match expression within a conditional expression) depends on the order in which parts are to be placed in a match expression, as well as conventions such as whether priority be set between conditional and match expressions. Requiring some redundant parentheses any way might help with avoiding bugs and/or making parsing easier (for programs as well as for human beings). Conditional expression seems to be taking this approach.

...

...

True if False if False else False else False File "<stdin>", line 1 True if False if False else False else False ^ SyntaxError: invalid syntax

Best regards, Takuo Matsuoka