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

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