|
|
Boost : |
From: shady mohamed (shadimabdrawy1999_at_[hidden])
Date: 2021-03-28 13:05:07
I want to talk with engineer david bellot and engineer cem bassoy
Thanks
ÙÙŠ الجمعة، ٢٦ مارس، ٢٠٢١ ١٢:٢٣ Ù… <boost-request_at_[hidden]> كتب:
> Send Boost mailing list submissions to
> boost_at_[hidden]
>
> 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_at_[hidden]
>
> You can reach the person managing the list at
> boost-owner_at_[hidden]
>
> 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 <akrzemi1_at_[hidden]>
> To: Boost mailing list <boost_at_[hidden]>
> Cc: Peter Dimov <pdimov_at_[hidden]>
> Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
> 2021 to March 31, 2021
> Message-ID:
> <CAOenAXhsJ1yCRRBYgJuPh8xws5MMVCks7p6GvfmBG+=
> 28QDNPg_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> 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;
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 25 Mar 2021 15:06:02 +0000
> From: Niall Douglas <s_sourceforge_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [release] 1.76.0 post-beta merges
> Message-ID: <6efb04af-9f26-4d04-a187-8bc08369caf3_at_[hidden]>
> 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#L35
> please.
>
> Niall
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 25 Mar 2021 17:24:15 +0200
> From: "Peter Dimov" <pdimov_at_[hidden]>
> To: "'Andrzej Krzemienski'" <akrzemi1_at_[hidden]>, "'Boost mailing
> list'" <boost_at_[hidden]>
> 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 <mclow.lists_at_[hidden]>
> To: Boost Developers List <boost_at_[hidden]>
> Subject: Re: [boost] [release] 1.76.0 post-beta merges
> Message-ID: <0EAF569D-A080-4217-BC77-D7CE4057EC0A_at_[hidden]>
> Content-Type: text/plain; charset=utf-8
>
> On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
> boost_at_[hidden]> 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#L35
> > please.
>
> Do you have a commit that fixes this?
>
> ? Marshall
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 25 Mar 2021 16:04:17 +0000
> From: Niall Douglas <s_sourceforge_at_[hidden]>
> To: Boost Developers List <boost_at_[hidden]>
> Subject: Re: [boost] [release] 1.76.0 post-beta merges
> Message-ID: <2dc9222a-592a-6b85-c76b-d62ef55611b3_at_[hidden]>
> 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_at_[hidden]> 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#L35
> >> 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 <glen.fernandes_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] [release] 1.76.0 post-beta merges
> Message-ID:
> <CAHVPgznFdSVYJ9gR8LzP7qQV7w5+fcjBvKq95ReUKkFR-ct=
> Qg_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Mar 25, 2021 at 12:04 PM Niall Douglas via Boost
> <boost_at_[hidden]> wrote:
> >
> > On 25/03/2021 15:45, Marshall Clow wrote:
> > > On Mar 25, 2021, at 8:06 AM, Niall Douglas via Boost <
> boost_at_[hidden]> 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#L35
> > >> 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 <julien.blanc_at_tgcm.eu>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID: <2773cbf43ec651fdf2b3a3262c8476d814047eb0.camel_at_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<unique_ptr<T>>. 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 <akrzemi1_at_[hidden]>
> To: Boost mailing list <boost_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID:
> <CAOenAXgEDx=
> kmKY5gVdST-oAeipoa2oG2s5j_y0brxs34r7ojw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> czw., 25 mar 2021 o 19:11 Julien Blanc via Boost <boost_at_[hidden]>
> 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<unique_ptr<T>>. 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 <julien.blanc_at_tgcm.eu>
> To: boost_at_[hidden]
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID: <54d581dd2987773250b0f822393ea819a03297bc.camel_at_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 <emildotchevski_at_[hidden]>
> To: Boost <boost_at_[hidden]>
> Subject: Re: [boost] [Boost] [Describe] Summary Review Summary
> Message-ID:
> <
> CAN5fK5H0Cr5OmaX2ryTjRcboLu8xqiv3eKuYdCaft6EZXKFh9Q_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Mar 24, 2021 at 7:35 AM Jeff Garland via Boost <
> boost_at_[hidden]> 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 <mathias.gaunard_at_[hidden]>
> To: Boost mailing list <boost_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID:
> <CALnjya9TV+n=N-0_8zWsu_+zGTAW=
> xezCsQ4C3vnBU6wZ6LkNw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 26 Mar 2021 at 04:54, Andrzej Krzemienski via Boost
> <boost_at_[hidden]> 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 <mathias.gaunard_at_[hidden]>
> To: Boost mailing list <boost_at_[hidden]>
> Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
> 2021 to March 31, 2021
> Message-ID:
> <
> CALnjya8bbeFs1d4q2pSbr8azU3aELbXVDtyCDtj+xioUDdkaEw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 22 Mar 2021 at 02:35, Joel de Guzman via Boost
> <boost_at_[hidden]> 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
> advantage
> > of the fact that the standard <functional> header already provides
> 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
> **************************************
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk