Inline functions / closures / lambdas

[chriseth]

Especially with generics ( #869 ) it might get more important to allow the definition of functions inline. There has also been a proposal to have require() take a custom error, and due to the evaluation rules, it might be an option to take a function that returns an error as the second parameter.
Both use-cases demand a shorthand notation to define inline functions like we have in python or rust.
Proposal:

The expression (Param...) => Expression evaluations to an internal function type that returns the value of the expression. The return type of the function is the type of the expression.
This can be shortened to => Expression if the parameters are empty.

If we want to allow full code blocks like in (Param...) => { ... }, we need explicit return statements and probably also return variables to be specified explicitly.

Capturing of local variables is a whole other problem.

[cameel]

I like the idea of something like require(c, => CustomError()). It's close enough to require(c, CustomError()) but also has enough extra syntax not to hide the fact that the second argument is lazily evaluated.

As for blocks vs single expression - personally I think that inline functions are best used for very concise one-liners and, if we exclude capturing variables, anything else should really be just a regular function definition with a good name. For example in C++ I find code peppered with long inline functions to be less readable than one with proper functions. As a bonus, not supporting statements would let us drop the return and make them even more concise (this is something that really bothers me about them in C++).

[cameel]

Older issue about lambdas: #911.

[cameel]

Potential use case for closures: #12816.