Re: [boost] Boost Digest, Vol 6566, Issue 1

28 Mar 2021


      I want to talk with engineer david bellot and engineer cem bassoy
Thanks

في الجمعة، ٢٦ مارس، ٢٠٢١ ١٢:٢٣ م  كتب:
...
Send Boost mailing list submissions to
        boost@lists.boost.org
To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.boost.org/mailman/listinfo.cgi/boost
or, via email, send a message with subject or body 'help' to
        boost-request@lists.boost.org
You can reach the person managing the list at
        boost-owner@lists.boost.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost digest..."
The boost archives may be found at: http://lists.boost.org/Archives/boost/
Today's Topics:
1. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to
      March 31, 2021 (Andrzej Krzemienski)
   2. Re: [release] 1.76.0 post-beta merges (Niall Douglas)
   3. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to
      March 31, 2021 (Peter Dimov)
   4. Re: [release] 1.76.0 post-beta merges (Marshall Clow)
   5. Re: [release] 1.76.0 post-beta merges (Niall Douglas)
   6. Re: [release] 1.76.0 post-beta merges (Glen Fernandes)
   7. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Julien Blanc)
   8. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Andrzej Krzemienski)
   9. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Julien Blanc)
  10. Re: [Boost] [Describe] Summary Review Summary (Emil Dotchevski)
  11. Re: [Lambda2] Review starts Monday March 22, 2021 to March
      31, 2021 (Mathias Gaunard)
  12. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to
      March 31, 2021 (Mathias Gaunard)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Mar 2021 14:54:17 +0100
From: Andrzej Krzemienski 
To: Boost mailing list 
Cc: Peter Dimov 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
pon., 22 mar 2021 o 16:44 Peter Dimov via Boost 
napisa?(a):
...
...
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
Edward Diener wrote:
this
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;
------------------------------
Message: 2
Date: Thu, 25 Mar 2021 15:06:02 +0000
From: Niall Douglas 
To: boost@lists.boost.org
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <6efb04af-9f26-4d04-a187-8bc08369caf3@nedprod.com>
Content-Type: text/plain; charset=utf-8
On 16/03/2021 20:24, Marshall Clow via Boost wrote:
...
The master branch is is now open for post-beta merges, but only as
described in the Post-Beta Merge Policy.
See <
https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy>
I would like to fix https://github.com/ned14/outcome/issues/249 by
improving the logic at
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
please.
Niall
------------------------------
Message: 3
Date: Thu, 25 Mar 2021 17:24:15 +0200
From: "Peter Dimov" 
To: "'Andrzej Krzemienski'" ,       "'Boost mailing
        list'" 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID: <131601d7218a$eb1033b0$c1309b10$@gmail.com>
Content-Type: text/plain;       charset="utf-8"
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.
------------------------------
Message: 4
Date: Thu, 25 Mar 2021 08:45:22 -0700
From: Marshall Clow 
To: Boost Developers List 
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <0EAF569D-A080-4217-BC77-D7CE4057EC0A@gmail.com>
Content-Type: text/plain;       charset=utf-8
On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
boost@lists.boost.org> wrote:
...
On 16/03/2021 20:24, Marshall Clow via Boost wrote:
...
The master branch is is now open for post-beta merges, but only as
described in the Post-Beta Merge Policy.
...
...
See <
https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy>
I would like to fix https://github.com/ned14/outcome/issues/249 by
improving the logic at
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
...
please.
Do you have a commit that fixes this?
? Marshall
------------------------------
Message: 5
Date: Thu, 25 Mar 2021 16:04:17 +0000
From: Niall Douglas 
To: Boost Developers List 
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID: <2dc9222a-592a-6b85-c76b-d62ef55611b3@nedprod.com>
Content-Type: text/plain; charset=utf-8
On 25/03/2021 15:45, Marshall Clow wrote:
...
On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
boost@lists.boost.org> wrote:
...
On 16/03/2021 20:24, Marshall Clow via Boost wrote:
...
The master branch is is now open for post-beta merges, but only as
described in the Post-Beta Merge Policy.
...
...
See <
https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy>
I would like to fix https://github.com/ned14/outcome/issues/249 by
improving the logic at
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
...
please.
Do you have a commit that fixes this?
The change is trivial. Current:
```c++
#if !defined(_MSC_VER) && !defined(__clang__) && (__GNUC__ < 9 ||
__cpp_concepts < 201907L)
#define OUTCOME_GCC6_CONCEPT_BOOL bool
#else
#define OUTCOME_GCC6_CONCEPT_BOOL
#endif
```
To be replaced with:
```c++
#if (defined(_MSC_VER) || defined(__clang__) || (defined(__GNUC__) &&
__cpp_concepts >= 201707) || OUTCOME_FORCE_STD_CXX_CONCEPTS) &&
!OUTCOME_FORCE_LEGACY_GCC_CXX_CONCEPTS
#define OUTCOME_GCC6_CONCEPT_BOOL
#else
#define OUTCOME_GCC6_CONCEPT_BOOL bool
#endif
```
To explain, GCC expects bool with concept, or not, in varying
configuration combinations which have evolved over GCC versions,
including apparently point releases, which is deeply unhelpful. This has
led to repeated bug reports for not just Outcome, but also for ASIO and
many other C++ projects.
If this above fix doesn't permanently shut this constant source of bug
reports, I'll be permanently disabling legacy GCC concepts support in
Outcome. I couldn't be arsed with supporting how unpredictably broken
GCC is with this.
Niall
------------------------------
Message: 6
Date: Thu, 25 Mar 2021 12:12:03 -0400
From: Glen Fernandes 
To: boost@lists.boost.org
Subject: Re: [boost] [release] 1.76.0 post-beta merges
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost
 wrote:
...
On 25/03/2021 15:45, Marshall Clow wrote:
...
On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
boost@lists.boost.org> wrote:
...
...
...
I would like to fix https://github.com/ned14/outcome/issues/249 by
improving the logic at
https://github.com/ned14/outcome/blob/develop/include/outcome/convert.hpp#L3...
...
please.
Do you have a commit that fixes this?
The change is trivial. Current:
If you're asking for permission to merge to master now, you should
have a commit on outcome's develop branch that we can look at. You are
free to commit to develop at any time. Only master is locked.
Glen
------------------------------
Message: 7
Date: Thu, 25 Mar 2021 19:10:33 +0100
From: Julien Blanc 
To: boost@lists.boost.org
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID: <2773cbf43ec651fdf2b3a3262c8476d814047eb0.camel@tgcm.eu>
Content-Type: text/plain; charset="UTF-8"
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).
...
?? - 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.
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
------------------------------
Message: 8
Date: Fri, 26 Mar 2021 05:54:36 +0100
From: Andrzej Krzemienski 
To: Boost mailing list 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
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
------------------------------
Message: 9
Date: Fri, 26 Mar 2021 07:44:43 +0100
From: Julien Blanc 
To: boost@lists.boost.org
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID: <54d581dd2987773250b0f822393ea819a03297bc.camel@tgcm.eu>
Content-Type: text/plain; charset="UTF-8"
Le vendredi 26 mars 2021 ? 05:54 +0100, Andrzej Krzemienski via Boost a
?crit?:
...
...
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.
Agreed. But I don't have a strong opinion on whether the library should
implement everything, or just be more open to user extensions.
...
The following als looks as something I would see often in the code:
assert(std::ranges::all_of(records, _1 != nullptr));
Definitely. That's the kind of motivating example that i think should
appear in the documentation.
Regards,
Julien
------------------------------
Message: 10
Date: Fri, 26 Mar 2021 00:23:56 -0700
From: Emil Dotchevski 
To: Boost 
Subject: Re: [boost] [Boost] [Describe] Summary Review Summary
Message-ID:
        <
CAN5fK5H0Cr5OmaX2ryTjRcboLu8xqiv3eKuYdCaft6EZXKFh9Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost <
boost@lists.boost.org> wrote:
...
...
The committee seems to be concerned more with internal and external
politics than with serving the community. If that wasn't true there
would
be ZERO library additions that haven't been battle hardened by being
deployed and established themselves as the defacto standard already.
Unlike the boost review where there's 'a decider', the committee uses
consensus.  It's a much higher bar, as frankly, it should be.
A "much higher bar" can prevent a good library from being accepted or
prevent a bad library from being rejected. That is, consensus cuts both
ways.
...
As for battle hardened, sometimes it's not quite so simple as sometimes
language changes are needed or vendor support is needed.  Every proposal
gets vetted for usage experience and it's clear that without experience
it's unlikely to go forward.  Is the process perfect -- no.  Will it make
everyone, even the members happy -- no.  Can it be improved -- surely --
but like many things in life it's not as simple as we'd like.
We can talk about the case when language changes are needed but let's focus
on libraries.
...
...
The only thing they should be doing is rubber-stamping libraries that
are
already the standard for doing something.
And if we 'just did that', things like generic programming wouldn't exist
in c++.  If the 'Roque Wave' container design was adopted in 1998 the
world
would be very different now.
There was no GitHub in 1998. Today it feels like some authors treat the
standard library as a vehicle for making their library available everywhere
in hopes it'll get adopted. All I'm saying is that adoption should come
before standardization. Git pull requests are better than Subversion
commits.
...
And if you want one of those 'battle hardened' libraries
adopted, that's fine
You see, I think it is problematic to "want" to standardize a library. IMO
the standardization process should be dull and boring, rather than driven
by exciting innovation.
------------------------------
Message: 11
Date: Fri, 26 Mar 2021 10:11:43 +0000
From: Mathias Gaunard 
To: Boost mailing list 
Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
        March 31, 2021
Message-ID:
        
Content-Type: text/plain; charset="UTF-8"
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.
------------------------------
Message: 12
Date: Fri, 26 Mar 2021 10:16:17 +0000
From: Mathias Gaunard 
To: Boost mailing list 
Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
        2021 to March 31, 2021
Message-ID:
        <
CALnjya8bbeFs1d4q2pSbr8azU3aELbXVDtyCDtj+xioUDdkaEw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost
 wrote:
...
The Boost formal review of the Lambda2, authored by Peter Dimov,
starts Monday, March 22, 2021 to March 31, 2021 (inclusive).
Documentation: https://pdimov.github.io/lambda2/doc/html/lambda2.html
Source: https://github.com/pdimov/lambda2/
Lambda2 is a simple, but functional, C++14 lambda library. It takes
...
of the fact that the standard <functional> header already provides
advantage
placeholders
...
_1, _2, _3, and so on, for use with std::bind, and function objects such
as std::plus, std::greater, std::logical_not, and std::bit_xor,
corresponding to
arithmetic, relational, logical and bitwise operators.
Please provide in your review information you think is valuable to
understand your choice to ACCEPT or REJECT including Lambda2 as a
Boost library. Please be explicit about your decision (ACCEPT or REJECT).
Some other questions you might want to consider answering:
- What is your evaluation of the design?
   - What is your evaluation of the implementation?
   - What is your evaluation of the documentation?
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?
What about the expression tree itself, is it fully by value, and
therefore safely copyable?
Boost.Proto for example by default is binding everything by reference,
meaning that you couldn't even store the expression in a variable. Is
it avoiding this issue?
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6566, Issue 1
**************************************

Re: [boost] Boost Digest, Vol 6566, Issue 1

shady mohamed