Implicit return in Mojo

[bomzj]

In Python we have to use return statement to return value from function:

def increment(x):
  return x + 1

Would it be possible to have implicit return like in functional programming, so functions always return something:

def increment(x):
  x + 1

[lattner]

No, because that is incompatible with python. In python, that function returns None, not the result of x+1.

[bomzj]

What about a new syntax where function is defined via fn?

[gryznar]

fn is kinda static version of def, so it is even more explicit. No return means return None or raise an error

[lattner]

Hi all, we're building the core Mojo type system right now, not adding tons of syntax sugar. I'm pretty opposed to adding syntactic sugar before the core language is settled. We need to get the bricks in place to get a sense of how the language is used in practice, we don't just add things "because we can".

[lattner]

I added this explanation to the roadmap:

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.