Abbreviated Lambdas for Fun and Profit

Contents

• Motivation
• Proposal
• => expr
• Omitting types
• Unary operator>>
• 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. It's not SFINAE-friendly and it's not noexcept-correct. Which could lead to avoidable errors:

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);             

// still error: no known conversion from std::string to int or Widget
invoke([](auto&& x) {       
    return test(std::forward<decltype(x)>(x));
});

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

And that's a lot to have to type. Which brings me to the second motivation: not having to write that. For simple lambdas, those lambdas whose entire body is return expr;, the noisy stuff you have to write to get it correct where you need to use it just drowns out the signal of what it was you wanted your lambda to do in the first place. That is assuming that I succeed in writing the same code in all three places without accidentally introducing subtle differences.

Arguably the only important code in the above block is that which has been marked in blue. All I want to do is test(x), why so much boilerplate?

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

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 211 characters to 38.

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

Sorting in decreasing order: roughly comparable typing, but arguably clearer:

std::sort(begin(v), end(v), std::greater<>{});  // C++14
std::sort(begin(v), end(v), [](x,y) => x > y);  // this proposal

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

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

Chaining lots of functions together from range-v3: summing the squares under 1000:

// C++14
int sum = accumulate(ints(1)
                   | transform([](int i){ return i*i; })
                   | take_while([](int i){ return i < 1000; }));
				   
// this proposal
int sum = accumulate(ints(1) | transform([](i) => i*i) | take_while([](i) => i < 1000));

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.

Omitting a type in a lambda could change the meaning of code today. For example:

struct arg { arg(int ) { } };
auto lambda = [](arg ) { return sizeof(arg); }
int x = lambda(1);

Unary operator>> cannot appear in legal code today, 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.

Acknowledgements and References

[1] Overload sets as function arguments

[2] Proposal for Generic (Polymorphic) Lambda Expressions

[3] Return type deduction and SFINAE