Any reason not to use global lambdas?

Question

We had a function that used a non-capturing lambda internal to itself, e.g.:

void foo() {   auto bar = [](int a, int b){ return a + b; }    // code using bar(x,y) a bunch of times } 

Now the functionality implemented by the lambda became needed elsewhere, so I am going to lift the lambda out of foo() into the global/namespace scope. I can either leave it as a lambda, making it a copy-paste option, or change it to a proper function:

auto bar = [](int a, int b){ return a + b; } // option 1 int bar(int a, int b){ return a + b; } // option 2  void foo() {   // code using bar(x,y) a bunch of times } 

Changing it to a proper function is trivial, but it made me wonder if there is some reason not to leave it as a lambda? Is there any reason not to just use lambdas everywhere instead of "regular" global functions?

Answer 1

There's one very important reason not to use global lambdas: because it's not normal.

C++'s regular function syntax has been around since the days of C. Programmers have known for decades what said syntax means and how they work (though admittedly that whole function-to-pointer decay thing sometimes bites even seasoned programmers). If a C++ programmer of any skill level beyond "utter newbie" sees a function definition, they know what they're getting.

A global lambda is a different beast altogether. It has different behavior from a regular function. Lambdas are objects, while functions are not. They have a type, but that type is distinct from the type of their function. And so forth.

So now, you've raised the bar in communicating with other programmers. A C++ programmer needs to understand lambdas if they're going to understand what this function is doing. And yes, this is 2019, so a decent C++ programmer should have an idea what a lambda looks like. But it is still a higher bar.

And even if they understand it, the question on that programmer's mind will be... why did the writer of this code write it that way? And if you don't have a good answer for that question (for example, because you explicitly want to forbid overloading and ADL, as in Ranges customization points), then you should use the common mechanism.

Prefer expected solutions to novel ones where appropriate. Use the least complicated method of getting your point across.