Abbreviated Lambdas for Fun and Profit

Contents

• Motivation
• Proposal
• => expr
• Unary operator>>
• Omitting type names
• Examples
• Effects on Existing Code
• Prior Work
• Acknowledgements and References

Motivation

There are two, somewhat related motivations for an abbreviated lambda syntax. The first is to address the problem of trying to pass in overload sets as function arguments [1]:

template <class T>
T twice(T x) { return x + x; }

template <class I>
void f(I first, I last) {
    transform(first, last, twice); // error
}

transform(first, last, [](auto&& x) {
    return twice(std::forward<decltype(x)>(x));
});

But that isn't actually correct, although it's the "obvious" code that most people would produce, and the problems are pretty subtle. The first problem is that it fails to return a reference where the function returned a reference, so there's an extra copy here in some cases (or just a hard error, if the type happens to be noncopyable). That's an easy fix though, just add the appropriate trailing return type:

transform(first, last, [](auto&& x) -> decltype(auto) {
    return twice(std::forward<decltype(x)>(x));
});

struct Widget;

bool test(int );
bool test(Widget );

void invoke(std::function<bool(int)> );         // #1
void invoke(std::function<bool(std::string)> ); // #2

// error: unresolved overloaded function type
invoke(test);             

// error with a really long stack trace
invoke([](auto&& x) -> decltype(auto) {       
    return test(std::forward<decltype(x)>(x));
});

The real, correct, way to lift an overloaded function into a function object would invole writing all of this (and even this version isn't noexcept-correct, which may matter in some cases!):

// finally OK: calls #1 invoke([](auto&& x) -> decltype(test(std::forward<decltype(x)>(x))) { return test(std::forward<decltype(x)>(x)); });

That's a lot to have to type for what's conceptually a very simple thing: passing a function, that happens to be overloaded, to a function template. That lambda in of itself is 108 characters long, most of which is boilerplate that drowns out the important parts of the call (which I highlighted in blue). That's far too long. Moreover, it's literally too long for many slides, so what you see at talks at conferences is typically people omit the perfect-forwarding for brevity's sake, and the forwarding syntax itself is so long that people just use macros:

#define FWD(x) static_cast<decltype(x)&&>(x) [](auto&& x) -> decltype(test(FWD(x))) { return test(FWD(x)); }

Now we're down to just 64 characters. This is a good deal better, and we can even wrap the entire lifting process into a lambda to make it even shorter, but do we really want to be in a position where we're recommending the use of macros?

Another place where this FWD macro comes especially handy is when we want to forward arguments into a lambda, just for normal purposes:

template <class T> void foo(T&& arg) { bar([arg=std::forward<T>(arg)]{ ... }); }

Again, that's so much to type. If I was copying arg, I could just type arg or =. If I was taking arg by reference, I could write &arg or &. But with forwarding, which is a fairly common operation, I need to write this 28-character beast (or, with macro, 13). But at least I can forward a single argument verbosely. With a parameter pack, I can capture the pack by copy or by reference, but to capture the whole thing by forward I would need to put it into a std::tuple. That seems very unsatisfying.

These all seem like major annoyances in modern C++. Too much code to write simple things.

Proposal

This paper proposes three language extensions. The extensions themselves are independent, but together combine to allow for terse, readable, correct lambdas and functions.

=> expr

The code duplication or triplication in short function bodies is also a common problem that wants for a solution [3], but this proposal is focused solely on lambda expressions.

Unary operator>>

This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary operator >>, where >>expr shall be defined as static_cast<decltype(expr)&&>(expr), and shall not overloadable. Furthermore, the symbol >> in the capture of a lambda expression can be used to "decay-copy" [4] the named variable or all variables.

This lambda:

[](auto&& x) { return test(>>x); }

[](auto&& x) { return test(std::forward<decltype(x)>(x)); }

This function (a one-time delayed invoker):

template <class F, class... Args>
auto delay_invoke(F&& f, Args&&... args) {
    return [>>]() => std::invoke(>>f, >>args...);
}

template <class F, class... Args>
auto delay_invoke(F&& f, Args&&... args) {
    return [f=std::forward<F>(f), tup=std::forward_as_tuple(std::forward<Args>(args)...)]() -> decltype(auto) {
        return std::apply(std::forward<F>(f), std::move(tup));
    };
}

Using >> to forward doesn't just make the code shorter. It makes it easier to read and easier to write. In the second example, it let's us naturally and directly invoke the function without having to do the indirection through a tuple (which is is neither easy to read nor write nor reason about). It's also probably easier for the compiler too.

Unary operator>> will have equivalent precedence to the other prefix operators, like operator!.

Omission of type names in lambdas

• Using a placeholder (e.g. :) to indicate that all type will be omitted. It would be impossible to specify an unnamed argument of a specific type.

  []@(x, y) // equivalent to [](auto&& x, auto&& y) []@(args...) // equivalent to [](auto&&... args) []@(int ) // ill-formed

• Using a placeholder (e.g. : or ^) for a particular argument to indicate that its type name is omitted. With each parameter individually marked, it would be possible to specify an unnamed argument

  [](@x, @y) // equivalent to [](auto&& x, auto&& y) [](@args...) // eqiuvalent to [](auto&&... args) [](@x, y) // equivalent to [](auto&& x, y <unnamed> )

• As in the original generic lambda proposal [5], allow for the omission of the type-specifier:

  [](&&x, &&y) // equivalent to [](auto&& x, auto&& y) [](const&... args) // equivalent to [](auto const&... args)

Examples

Putting all three features together, binding an overload member function, func, to an instance, obj, as a function argument is reduced from:

[&obj](auto&&... args) noexcept(noexcept(obj.func(std::forward<decltype(args)>(args)...))) -> decltype(obj.func(std::forward<decltype(args)>(args)...)) { return obj.func(std::forward<decltype(args)>(args)...); }

[&obj](args...) => obj.func(>>args...)

That is a reduction from 212 (144 if you don't care about noexcept) characters to 39.

Here are other examples of improved usage as compared to C++14 best practices.

Sorting in decreasing order: same typing, but arguably clearer:

std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x > y; }); // C++14 std::sort(begin(v), end(v), std::greater<>{}); // C++14 with function object std::sort(begin(v), end(v), [](x,y) => x > y); // this proposal - don't need to know about std::greater

Sorting in decreasing order by ID:

std::sort(begin(v), end(v), [](auto&& x, auto&& y) { return x.id > y.id; }); // C++14 std::sort(begin(v), end(v), std::greater<>{}, &Object::id); // ranges with projections std::sort(begin(v), end(v), [](x,y) => x.id > y.id); // this proposal

Finding an element based on a member function call, with and without additional arguments:

auto it = std::find_if(begin(v), end(v), [](auto&& e) { return e.isMatch(); }); // C++14 with lambda auto it = std::find_if(begin(v), end(v), std::mem_fn(&Object::isMatch)); // C++11 with mem_fn auto it = std::find_if(begin(v), end(v), [](e) => e.isMatch()); // this proposal auto it = std::find_if(begin(v), end(v), std::bind(&Object::matches, _1, std::ref(target))); auto it = std::find_if(begin(v), end(v), [&](auto&& e) { return e.matches(target); }); auto it = std::find_if(begin(v), end(v), [&](e) => e.matches(target));

Calling an overload where SFINAE matters and getting it wrong is a mess:

bool invoke(std::function<bool(int)> f);         // #1
bool invoke(std::function<bool(std::string)> f); // #2

invoke([](auto x) { return x == 2; });                     // error! (283 lines of diagnostic on gcc)
invoke([](auto x) -> decltype(x == 2) { return x == 2; }); // OK C++14: calls #1
invoke([](x) => x == 2);                                   // OK this proposal: calls #1

Implementing currying, in C++17. This is dramatically more concise than what you would otherwise have to do in C++17 [6], thanks to being able to capture parameter packs by decay-copy and easily get the SFINAE right (here it is critical) without duplication.

template <class F> auto curry(F&& f) { return [>>](auto&&... args) -> decltype(auto) { if constexpr (std::is_callable<F&(decltype(args)...)>::value) { return std::invoke(f, >>args...); } else { return curry([>>, f](auto&&... new_args) => std::invoke(f, args..., >>new_args...) ); } }; }

Effects on Existing Code

The token => can appear in code in rare cases, such as in the context of passing a the address of the assignment operator as a template non-template parameter, as in X<Y::operator=>. However, such usage is incredibly rare, so this proposal would have very limited effect on existing code. Thanks to Richard Smith for doing a search.

Unary operator>> cannot appear in legal code today, or in this proposed context in a lambda-capture, so that is a pure language extension.

Prior Work

The usage of => (or the similar ->) in the context of lambdas appears in many, many programming languages of all varieties. A non-exhaustive sampling: C#, D, Erlang, F#, Haskell, Java, JavaScript, ML, OCaml, Swift. The widespread use is strongly suggestive that the syntax is easy to read and quite useful.

There has also been an idea floating around, if not a specific proposal, to lift an overloaded function into a lambda with the syntax []f. This is certainly far more concise than what is proposed as an alternative in this paper ([](args...) => f(>>args...)).

Acknowledgements and References

[1] Overload sets as function arguments

[2] Pack expansions in using-declarations

[3] Return type deduction and SFINAE

[4] [thread.decaycopy] defines this as

template <class T> decay_t<T> decay_copy(T&& v) { return std::forward<T>(v); }

[5] Proposal for Generic (Polymorphic) Lambda Expressions

[6] zero-overhead C++17 currying & partial application, most of the implementation revolves around properly forward-capturing the parameter packs