Extend assignment function notation

I think it would be useful if “match” and “case” statements were actually expressions. For example, I’d like to be able to do things like:

def whats_this(foo) =
    case foo:
        match 0:
            #<do something>
            "Zero"
        match 1:
            #<do something else>
            "One"
    else:
        "Dunno"

assert "Zero"   == whats_this(0)
assert "One"    == whats_this(1)
assert "Dunno"  == whats_this(2)

[evhub]

@Nexus6 Yeah, I totally agree that this would be useful–it’s something I’ve been wanting to implement since I resolved #159. Putting this issue on the v1.2.1 milestone.

[akdor1154]

Its not so much about filling use case checkboxes, it’s more (again, just from user perspective here) about consistency.

There are already special cases that work towards this: your alternative ternary operator (not needed if if is an expression), statement lambdas (would be sometimes not needed if def fn is an expression), probably more…

With everything-is-expression, the above special cases mostly become unnecessary, and the requests for other special cases (why not a match expr to go with ternary expr? Why does a statement lambda on my last line return a func, but a def func return None?) go away.

As before, the languages Coconut is inspired by largely work this way already - as a user I find the python ‘actually this thing is a statement and will silently eval to None’ paradigm to be jarring in Coconut’s otherwise functional environments.

In practice with these other languages I haven’t noticed an issue with clarity around what a deeply nested expression returns - as long as there is clear syntax to delineate the expression as a unit, which Py/Coconut’s whitespace does beautifully.