Document number: DxxxxR0

Barry Revzin
2016-10-10

Abbreviated Lambdas for fun and profit

Contents

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
}
C++14 generic lambdas allow us a way to solve this problem by just wrapping the overloaded name in a lambda:
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));
});
You'd really have to write:
// 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 the creation of a new lambda introducer, =>, which allows for a single expression in the body that will be its return. This will synthesize a SFINAE-friendly, noexcept-correct lambda by doing the code triplication for you.

At its simplest:

[](auto&& x) => test(x)
shall be exactly equivalent to the lambda:
[](auto&& x) noexcept(noexcept(test(x))) -> decltype(test(x)) {
    return test(x);
}
But since auto&& has become such a regular choice of argument for lambdas, that too can become optional. An omitted type would be assumed as auto&&. Moreover, since the token => cannot appear in C++ code currently, we can even make the capture brackets optional for no-capture lambdas. And, for non-capturing lambdas that take a single argument, the parentheses around the argument can be optional as well. That is, introducing:
[](x) => test(x) // equivalent to the above
(x) => test(x)   // equivalent to the above
x => test(x)     // equivalent to the above
Multiple arguments would still have to be parenthesized.

One of the last sources of boilerplate is std::forward. In a lot of generic code, the uses of forward overwhelm all the rest of the code, to the point where many talks and examples just omit references entirely to save space. I'm occasionally tempted to introduce a macro (#define FWD(x) decltype(x)(x)) which is just wrong. This paper would like to see a shorter way to forward arguments and proposes non-overloadable unary operator >>. Putting it all together we get:

// old way
transform(first, last, [](auto&& x) noexcept(noexcept(test(std::forward<decltype(x)>(x))))
	-> decltype(test(std::forward<decltype(x)>(x)))
{
    return test(std::forward<decltype(x)>(x));
});

// proposed new way
transform(first, last, x => twice(>>x));

Examples

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

Binding an overloaded member function that takes arbitrarily many arguments to an instance, even without noexcept-correctness:

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

// this proposal
[&obj](auto&&... args) => obj.func(>>args...)

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

// with UFCS
int sum = ints(1).transform(i => i*i).take_while(i => i < 1000).accumulate();

Effects on Existing Code

Neither the token => nor a usage of unary operator>> can appear in legal code today, so no currently existing code behavior would be changed. This is a pure language extension.

[1] Overload sets as function arguments