pon., 22 mar 2021 o 16:44 Peter Dimov via Boost
My first reaction, after quickly looking at the submission, is what does
library offer that the original lambda library, which appears to have a much larger amount of functionality than this lambda2 library, not offer ? Also there is the Phoenix library, which also offers an even greater amount of function object and lambda-like functionality, of which the review manager is the
Edward Diener wrote: this main
author I believe.
Purely from a user perspective, what this library offers is being a lightweight, single header dependency, and...
Is it basically so that the programmer can easily interface with the std::bind/std::function classes with the lambda2 placeholders, whereas the C++03 libraries don't have this possibility wit their placeholders ?
... indeed, a way to port boost::bind code that uses its operators to std::bind, something that comes up from time to time as projects are modernized.
From a different perspective, another goal of the submission is to gather experience and provide a tested and widely available implementation for an eventual proposal to add this functionality to the standard. (Better late than never.)
My opinion so far is that there is not enough motivation to warrant the addition of this library into Boost. First, the design goals, or the purpose, of the library is not clearly defined. 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. Just look at the motivating examples of Boost.Lambda: https://www.boost.org/doc/libs/1_75_0/doc/html/lambda/using_library.html In particular, the usage of assignment or function constant(). Boost.Lambda2 will not work as a drop-in replacement for Boost.Lambda. 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 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. std::bind only works well when it is used for binding arguments to functions. Overusing it for implementing lambdas made sense in C++03, because there was no other way. Now with generic lambdas it can only be considered a bad (or at least controversial) practice. I am far from imposing my programming style on others. But promoting a programming style like this through the inclusion into Boost seems too much. My vision of Boost is that it should support certain programming styles that are considered good, but not any programming style. Regarding the implementation, on the other hand, it is as elegant as a library implementation could ever be. It is extremely short! (78 lines, including whitespace, header guards, and copyright notice). Regards, &rzej;