Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to March 31, 2021

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-03-25 15:24:15

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.