On 22/03/2021 5:48 pm, Robert Ramey wrote:

I have a really dumb question about this.  Consider the count_if example.  I understand how example works.  But I can't figure out where the parameter _1 gets filled in. So I think that the count_if example should be completed with a small bit of code which uses the newly count_if function.

The _1 parameter is filled in by std::count_if itself (in this case, using each element of the passed iterators). That's the point of a lambda, so I'm not quite sure what you're unclear on. This is not creating a "count_if" function, if that's what you thought; it is a complete example including both definition and usage. Having said that, I do think the docs could benefit by having some "compare and contrast" examples -- i.e. showing how each of those examples would have been implemented using C++11 lambdas or std::bind instead (and thus demonstrate the syntactic benefits of the library).

On 3/22/21 9:43 AM, Peter Dimov via Boost wrote:

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...

This should not be under appreciated! I've been working for a boost-bigoted company for the last 5 years and generally limited to C++11 until this month. Having access to Peter's minimal-dependency header-only libraries of late have been a boon to my efforts to modernize our code base. While developers here bristle at bringing in all of boost, there have been no complaints on bringing in mp11, or even the non-boost asio distribution.

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.

Phil Endecott wrote:

Peter Dimov wrote:

...

The goals of the library are [...] - Prepare a proposal to extend the standard with these same additions by gathering experience in Boost first.

Am I correct in thinking that this functionality could have been added to the standard library when std::bind was added in C++11, except that it requires something in the core language that was not added until C++14 ?

Return type deduction makes it easier to write, and the function objects in <functional> acquired their <void> forms in C++14, but it's possible to make this work in C++11 as well.

If not, what is the reason why this was not added when std::bind was added? (I've failed to locate any pre-C++11 WG21 papers about std::bind.)

I didn't propose it. :-)

On Thu, 8 Apr 2021 at 07:12, Joel de Guzman via Boost wrote:

Hello Y'all,

Thank you all who participated in the review of Lambda2 and thank you Peter for submitting the library.

Boost.Lambda2 is now officially accepted into Boost.

Thank you Joel for managing the review and congratulations to Peter. I've updated the review schedule. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Edward Diener wrote:

I also could not decipher what in the world "All operators defined in the subsequent sections only participate in overload resolution if at least one of their operands is such that for its unqualified type T, the expression std::is_placeholder<T>::value || std::is_bind_expression<T>::value is true" means in practical terms. I I see no 'T' s in the subsequent sections, and am just confused.

This just says "at least one of the operands must be a bind expression or a placeholder." `T` in the above is the unqualified type of the operand.

Rainer Deyke wrote:

So here's my first impression. It's simple, clean, and elegant. However, it doesn't appear to solve any problem I have. In a world where C++ already has "real" lambda expressions as a language feature, is there any need for another lambda library?

I assume that the appeal of lambda2 is that it involves less typing.

My impression is similar. I've just gone through my current codebase looking for lambdas that I could re-write using this syntax. Most can't, even the short ones, because I invoke functions or access members, and fn(_1) and _1.field aren't possible. Even when the placeholder form is possible, I lose my meaningful parameter names and possibly types. Pre-C++11 I used to have code that used boost::lambda or similar, but I converted it all to use core language lambdas years ago. I guess that if there are people who still have code using boost::lambda, they may find that they can use lambda2 as a near drop-in replacement and maybe get faster compilation, or something. But I would suggest that they should grasp the nettle and update to just use core-language lambdas. Are there any cases where converting an old boost::lambda expression to a core-language lambda is particularly problematic? Regards, Phil.

Fletcher, John P wrote:

Hi

I did some tests with lambda2 some time ago and the review release seems to be the same. One of the useful things in the old lambda is this example:

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

I could not get this to work with lambda2. I am not in a position to run my tests again at the moment. It would be good if this example did work.

Despite being deceptively simple, this is actually a pretty thorny example for lambda libraries. First off, Lambda2 doesn't even support operator<<, because there's no such function object in <functional>, but let's suppose we fix that. Then, there are two additional obstacles. First, std::cout needs to be taken by reference, but lambda libraries traditionally default to capture by value, and by-ref captures need to be marked with std::ref (or boost::ref). Boost.Lambda gets around that by hardcoding std::ostream& to be taken by reference by default. Second, std::endl is a function template, so template argument deduction of the second operator<< fails against it. Boost.Lambda fails on this one: https://godbolt.org/z/Ec4MYhG56 Boost.Phoenix works as-is, probably by special-casing the stream manipulators: https://godbolt.org/z/5z6vc3bT9 It'd be easy to make the version std::ref(std::cout) << _1 << '\n' work with Lambda2, but the example as-is requires more substantial changes.

Fletcher, John P wrote:

...

Hi

I did some tests with lambda2 some time ago and the review release seems to be the same. One of the useful things in the old lambda is this example:

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

I could not get this to work with lambda2. I am not in a position to run my tests again at the moment. It would be good if this example did work.

Despite being deceptively simple, this is actually a pretty thorny example for lambda libraries.

Looks like I mentally replaced ' ' with std::endl in the above, sorry. :-)

Richard Hodges wrote:

So I settled on this:

std::transform(source.begin(), source.end(), dest.begin(), uppercase < _1);

:-) FWIW, the "idiomatic" way is to use `std::bind( uppercase, _1 )`, although in this specific case this can be shortened to just `uppercase`.

At this point I was presented with a dilemma. On the one hand, the library is concise, correct, limited in scope and well documented. On the other, it doesn't do anything other than remove a few keystrokes in the rare case that I want a lambda to do some adding up or taking away.

That's basically what it's about for new code, removing a few keystrokes (if we discount the use cases related to porting existing Boost.Bind or Boost.Lambda code to C++14.) The motivation comes from the various "abbreviated lambda" proposals, which aim to provide an alternative, more concise, syntax for core language lambdas. There's a good blog post by Barry Revzin about the verbosity of C++ lambdas compared to other languages: https://brevzin.github.io/c++/2020/06/18/lambda-lambda-lambda/ The goal here is to make simple lambdas shorter, not to compete with the core language lambdas in all cases, which is neither possible nor necessary. If you just need to say _1 < 0, or _1 < x, or _1 * 2 + 1, the language lambda boilerplate takes up more than 50% of the whole thing. If, on the other hand, you need to express something more complex than Lambda2 can handle, switch to the language lambda.

On Wed, 24 Mar 2021 at 17:57, Peter Dimov via Boost wrote:

...

The goal here is to make simple lambdas shorter, not to compete with the core language lambdas in all cases, which is neither possible nor necessary.

If you just need to say _1 < 0, or _1 < x, or _1 * 2 + 1, the language lambda boilerplate takes up more than 50% of the whole thing. If, on the other hand, you need to express something more complex than Lambda2 can handle, switch to the language lambda.

Why not add some nice syntactic sugar to the shipping library, i.e. something like this: template< typename A, typename F> int operator+= (A&& a, F&& f) {return std::count_if( a.cbegin(), a.cend(), f);} template void operator<<= (T& a, F fun) { std::transform(std::begin(a), std::end(a), std::begin(a), fun); } so that the lazy people can write: std::vector<int> v ={3,1,4,1,5,9,2,6,5,3,5,9}; std::cout << "Count even elements: " << (v += (_1 % 2 == 0)) << "\n"; v <<= _1*_1; for(auto i : v) std::cout << i << ' '; std::cout << '\n'; std::cout << "Count even elements: " << (v += (_1 % 2 == 0)) << "\n Still three!\n"; Happy April 1st, K

czw., 25 mar 2021 o 19:11 Julien Blanc via Boost napisał(a):

Le lundi 22 mars 2021 à 10:35 +0800, Joel de Guzman via Boost a écrit :

...

The Boost formal review of the Lambda2, authored by Peter Dimov, starts Monday, March 22, 2021 to March 31, 2021 (inclusive).

Here's my small review of the lambda 2 library.

TLDR: ACCEPT

...

- What is your evaluation of the design? - What is your evaluation of the implementation?

The library is a really small piece of code, like other reviewers already noticed. During my tests, i came across two things that could be improved: * the internal macro BOOST_LAMBDA2_UNARY_LAMBDA and BOOST_LAMBDA2_BINARY_LAMBDA #undefed at the end of the file. While i undestand that it is an internal macro, it could be exposed to the user to allow implementation for other operators * that macro hardcode the std prefix, it could be part of its call, ie:

BOOST_LAMBDA2_BINARY_LAMBDA(+, std::plus) // instead of BOOST_LAMBDA2_BINARY_LAMBDA(+, plus)

This would allow the user of the library to get the building blocks to customize other operators to its needs (I have implemented unary operator* easily that way).

Is it not just that the library is missing some operators? If Boost.Lambda2 overloaded all overloadable operators there would be no point in users doing it.

...

- What is your evaluation of the documentation?

The documentation is really good at telling what the library does, is clean, nice looking.

...

- What is your evaluation of the potential usefulness of the library?

At first glance, i was thinking that this was the kind of library that i would never use. I find the count_if examples in the documentation not really convincing.

Then, it happened that i made some experiments with c++20 ranges. And i find that, in this context, shortening the lambdas gives a real benefit to the code. It basically started from the need to feed a function that was needing a list of non owner references to T from a vector. As I was not satisfied with the solution, I checked whether c++20 ranges could provide an elegant solution to this. Something like

f(std::views::transform(vec, deref));

implementing deref is easy. Then, out of curiosity, i checked if i could use Peter's library to be able to write something like:

f(std::views::transform(vec, *_1));

I actually find that this way of writing is more natural than the former.

This is an interesting observation. In my experience, storing collections of ints is a rare case in production code (it is frequent in tests, tutorials, books, presentations), maybe this is why arithmetic operators do not appear as something practical. However pointers (including smart ones) to user-defined types is something that I see a lot. The following als looks as something I would see often in the code: assert(std::ranges::all_of(records, _1 != nullptr)); Regards, &rzej;

So, i wrote :

namespace std // BAD, don't do that { template<typename T = void> struct deref { decltype(auto) operator()(T& v) { return *v; } }; template<> struct deref<void> { template<typename T> decltype(auto) operator()(T& v) { return *v; } }; }

BOOST_LAMBDA2_UNARY_LAMBDA(*, deref);

modified Peter's library to remove the #undef, and voila, it just works.

I see a lot of potential for the short writing form for lambdas, in conjunction with the ranges library. I find convenient to write:

f(std::views::transform(vec, _1 + 1)) // convert from 0-based to 1- based index

...

- Did you try to use the library? With which compiler(s)? Did you have any problems?

No specific issue encountered, with gcc-10. Error messages are a bit cryptic.

...

- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

A few hours playing with the library.

...

- Are you knowledgeable about the problem domain?

Not at all.

My feeling is the following. At first glance, i was wondering what was the use case the library addressed. After playing a bit with it, i'm now convinced that people will want to use it, and, like me, will probably want to expand it to fit their need. I was not suspecting that it was possible to write code that way. I suspect most developers are not either. Now that it is known it's possible, people will come up with their own, probably inferior, solution. Having such a feature in boost would at least provide everyone with a correct implementation of it. Because people will want to write code like this, and i believe, especially with ranges.

Thanks to Peter for writing this library, and proposing it to boost. Reviewing it has been very interesting and instructive.

Regards,

Julien

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost wrote:

This is an interesting observation. In my experience, storing collections of ints is a rare case in production code (it is frequent in tests, tutorials, books, presentations), maybe this is why arithmetic operators do not appear as something practical.

They do appear frequently if you use column-oriented data structures, which are generally better at dealing with large collections of data.

Hey everyone, I vote to *ACCEPT *Lambda2. I first heard of Lambda2 when Peter asked me how many lines I thought it would take to recreate Boost.Lambda. Naturally, I should've seen this as a loaded question but I guessed a few hundred. Maybe something just below a couple thousand by the time all the dust settles. Peter told me it could be done in ~50 lines. Now I was intrigued. The source code of Lambda2 is wonderfully clever and short. Moreso, sufficiently clever that it's worth not repeating every time we want to use it. Higher-order functions are all the rage in C++ and writing lambdas is cumbersome and annoying. Lambda2 gives us a C++14 solution that relies on nothing else but simple language features and stdlib headers making it faster to compile than older solutions such as Phoenix or the original Lambda. Lambda2 also has the fortune of interop'ing greatly with existing constructs like Boost.HOF and the new `<ranges>` STL header. See: https://godbolt.org/z/hfxfhfEqv Keeping this short, Lambda2 gives us fresh paint over an old technology that we know works and one that (while polarizing in its style) does its job well. I think it ultimately serves Boost and the larger C++ community to keep this Lambda-style of coding alive and well-maintained as C++ evolves. - Christian

Mathias Gaunard wrote:

It is not clear from the documentation what the capture behaviour of terminals is. I assume it's capturing rvalues by value and lvalues by reference?

The capture behavior is inherited from std::bind, which captures everything by value by default unless overridden with std::ref.