Andrzej Krzemienski wrote:
First, the design goals, or the purpose, of the library is not clearly defined.
The goals of the library are - Give people the choice of using an abbreviated lambda syntax that is able to express simple operations in fewer characters; - Bring std::bind to parity with boost::bind feature-wise so that porting is easier; - Prepare a proposal to extend the standard with these same additions by gathering experience in Boost first.
Is the goal that tandem std::bind + Boost.Lambda2 should be a replacement over boost::bind and Boost.Lambda? If so, in the current form of the library the goal will not be satisfied, because current Boost.Lambda offers quite more things.
This doesn't make it useless. When porting "operator-enhanced" boost::bind, or Boost.Lambda, code, you need to go over all the uses and change them into language lambdas. This is routine mechanical work that as a result is highly error-prone and without good test coverage, mistakes can easily pass review because of the repetitive nature of the diff. It's much better if you could port at least some of the uses without making changes beyond replacing boost:: with std::, and adding/changing the using directive. It's not necessary to be able to port _all_ uses without any changes; a portion is enough to reduce the error rate significantly. And if you're going to ask what's the point of porting from one Boost library to another, the difference is that it's much easier to "vendor" a single short header.
For a moment I thought that the goal is to have a cooler syntax for the current standard arithmetic function objects, such as std::plus, std::multiplies. But the advantage is dubious. You gain a few characters, but you pay the cost of * employing a different library * messy error messages * no debugger support
This could be true, but it has nothing to do with the library lacking clarity of purpose.
The suggestion that we would enable constructs like `std::bind(&Employee::name, e1) < std::bind(&Employee::name, e2)`also doesn't seem like a good motivation.
As explained, this is only an issue when porting boost::bind code using these constructs. You obviously aren't going to use this in new code because the equivalent language lambda is shorter (not by much) and clearer.