Implement Pattern Matching as expression instead of statement in Mojo

[bomzj]

Do you consider implementing Pattern Matching as an expression, to step out from C-legacy(lots of return statements that lead to bad/mutable code) and make Mojo a modern language with functional style features that currently missing in Python?

[gryznar]

Could you explain that more? I am coming directly from Python in which structural pattern matching (match-case) is just advanced syntatic sugar for if-else statement which of course does not gives additional profit in terms of speed comparing to typical switch-case statement.

[bomzj]

@gryznar expressions produce a value e.g. 5 + 6 while statements like if do not. So expression can be assigned to a variable or passed to a function while statements can't be assigned to or passed in.
Just imagine the following:

result =
  if x == y: "equals"
  elif x < y: "is less than"
  else "is greater than"

This is absolutely normal behaviour in functional languages like F#, Elixir, Haskel and etc.

[gryznar]

Thanks, but I mean rather in terms of your proposition :)

What advantage it will give over Python

[ksandvik]

Python match is very flexible and as Mojo is a Pythonic language that will track the Python syntax, that's basically all we need.

[gryznar]

I think the same. Mojo version could be only much more optimized

[lattner]

Hi all, per the roadmap, we are not implementing syntactic sugar features right now:

In the near-term, we will not prioritize "general goodness" work such as:

• Adding syntactic sugar and short-hands for Python.

I will add more rationale to the roadmap, because this is frequently asked.

[lattner]

I added this to the roadmap doc:

Why not add syntactic sugar or other minor new features?

We are frequently asked whether Mojo will add minor features that people love
in other languages but that are missing in Python, e.g. things like "implicit
return" at the end of a function, public/private access control, fixing Python
packaging, and various syntactic shorthands. As mentioned above, we are
intentionally not adding these kinds of features to Mojo right now.
There are three major reasons for this:

First, notice that Mojo is still young: we are still "building a house" by
laying down major bricks in
the type system and adding system programming features that Python lacks. We
also know we need to implement support many existing Python features for
compatibility (a massive and important goal of Mojo) and this work is
not done yet. We have limited engineering bandwidth and want to stay focused on
building essential functionality, not even taking time to debate whether
syntactic sugar is important or not.

Furthermore, second, syntactic sugar is like mortar in a building - its
best use is to hold the building together by filling in usability gaps. Sugar
(and mortar) is problematic to add early into a system: you can run into
problems with laying the next bricks because the sugar gets in the way. We have
experience building other languages (e.g. Swift) that added sugar early that
could have been subsumed by more general features if time and care were given
to broader evaluation.

Third, there is Python and the Python community. It is important to us that
Mojo be a good member of the Python family (a "Python++"), not just a language
with Pythonic syntax. As such, we don't want to needlessly diverge from Python
evolution: adding a bunch of features could lead to problems down the road if
Python makes incompatible decisions. Such a future would fracture the
community which would cause massively more harm than any minor language feature
could offset.

For all these reasons, "nice to have" syntactic sugar is a priority, and
proposals will get rapidly closed (to avoid cluttering the issue
tracker). If you'd like to propose a "general goodness" syntactic feature,
please do so with the existing Python PEP
process. If/when Python adopts a feature,
Mojo will add it - because Mojo's goal is to be a superset. We are happy with
this approach because the Python community is better equipped to evaluate these
features, they have mature code bases to evaluate them with, and they have
processes and infrastructure for making structured language evolution features.

[mojodojodev]

Looks good, just a couple minor typos:

add for:

we also know we need to implement support for many existing Python features"

add not:

For all these reasons, "nice to have" syntactic sugar is not a priority

[lattner]

thanks!