C++0x lambdas suck

int x = 3 ;
int y = 2 ;
vector<int> v = { 1, 2, 3, 4, 5, 6 } ;

sort(v.begin(), v.end(), [=x, &y](int lhs, int rhs) { return (lhs & x) < (rhs & y); }) ;

Ok – I stretched there to incorporate the capture in all it’s glory (the capture is the [=x,&y]).

Lets be frank here. The purpose of a lambda function is to be able to create a little snippet of code to be executed inside a loop.

Does C++ need it? IMHO, lambda functions are bad. And C++0x’s choice to make them hideously ugly doubly so.

The ability to stuff multiple instructions into a single line is a topic of much debate. Maintenance programmers hate it – most maintenance programmers go by the rule of 1; that is, one operation per line.

Lambda functions are an encouragement to stuff not just multiple operations into one line but multiple statements into one operation.

sort(v.begin(), v.end(), [=x, &y](int lhs, int rhs) {
  lhs *= x ;
  rhs /= y ;

  return (x < y) ;
}) ;

C++ already has passable mechanisms for lambdas and captures in the form of function objects. And I think moving away from clearer, easier to maintain code is like choosing blue rinse to cover your gray hairs.

For very simple operations, it is nice to be able to put the operation inside the sort…

sort(v.begin(), v.end(), { return arg1 < arg2 ; });

Having to create a whole function body for that is a bit mindless.

There are two other motivations for people wanting formally defined lambdas and closures in C++: clutter and, well, clutter.

With current C++, creating function objects is a bit of a pain because they have to be done out-of-line. You can’t define a function object inside a function definition, it has to be done at a higher scope level, which makes for cluttered reading. And the syntax for doing it with structs and classes is currently convoluted (if you are doing a closure, you have to write a constructor, blah blah blah).

I would have preferred something like:

int myFn(vector<Object*> a, int index) {

  lambda int SortObjectsByPointer (Object* lhs, Object* rhs) {
    return lhs < rhs ;
  }

  sort(a.begin(), a.end(), SortObjectsByPointer) ;

  closure SortObjectsByIndex(int index) {
    int (Object* lhs, Object* rhs) {
      return lhs->data[index] < rhs->data[index] ;
    }
  }

  sort(a.begin(), a.end(), SortObjectsByIndex) ;
}

In the above closure, “int index” captures the current value of ‘index’, if I wanted to capture a reference to it, I’d write “int& index”.

The above given example, though, would expand itself out to the equivalent of:

class myFn::SortObjectsByIndex {
  int index ;
public:
  SortObjectsByIndex(int _index) : index(_index) {}
  int operator()(Object* lhs, Object* rhs) {
    return lhs->data[this->index] < rhs->data[this->index] ;
  }
}

sort(a.begin(), a.end(), SortObjectsByIndex(index)) ;

As far as I can tell, C++0x actually tackles several of the side issues that make function objects less desirable than proper lambda functions. But on the whole, what people want is recognition of this very common coding practice and a formal expression for it so that the code more readily self annotates. The expanded version above does its job, functionally, but it is full of irrelevant boilerplate.

C++0x lambdas/closures are going to be a pain in the derrière. For a start, which is which is distinguishable by whether you used [=] or [&] or a variant thereof…