|
Boost : |
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2021-03-25 13:54:17
pon., 22 mar 2021 o 16:44 Peter Dimov via Boost <boost_at_[hidden]>
napisaÅ(a):
> Edward Diener wrote:
> > My first reaction, after quickly looking at the submission, is what does
> this
> > 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
> 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;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk