|
|
Boost : |
From: Chandana Gubba (chandanagubba_at_[hidden])
Date: 2021-03-28 14:33:49
Sir/madam I does not have that great idea regarding Gsoc ,so firstly I want
to know what about it exactly and how to apply and do project,and even
about the eligibility ,I am ok with c++ programming. Is it enough ,these
are my queries regarding gsoc.
On Sun, 28 Mar, 2021, 7:20 pm , <boost-request_at_[hidden]> wrote:
> 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 (Peter Dimov)
> 2. Re: [Lambda2] Review starts Monday March 22, 2021 to March
> 31, 2021 (Peter Dimov)
> 3. To contact project's mentor for GSoC21 (prince raj)
> 4. Re: To contact project's mentor for GSoC21
> (Vin?cius dos Santos Oliveira)
> 5. Re: To contact project's mentor for GSoC21 (Mateusz Loskot)
> 6. Re: [Lambda2] Review starts Monday March 22, 2021 to March
> 31, 2021 (Christian Mazakas)
> 7. Re: [Boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021 (Emil Dotchevski)
> 8. Re: [Lambda2] Review starts Monday March 22, 2021 to March
> 31, 2021 (Phil Endecott)
> 9. Re: [Lambda2] Review starts Monday March 22, 2021 to March
> 31, 2021 (Peter Dimov)
> 10. [Boost][GIL][GSOC 2021] Contribute to the library
> (sayan chaudhuri)
> 11. (no subject) (Suraj Nehra)
> 12. [GSoC] Boost.Real: Introduction and Guidence (Suraj Nehra)
> 13. Changelog for 1.76 is outdated (Antony Polukhin)
> 14. Re: Changelog for 1.76 is outdated (Antony Polukhin)
> 15. Re: Boost Digest, Vol 6566, Issue 1 (shady mohamed)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 26 Mar 2021 14:10:43 +0200
> From: "Peter Dimov" <pdimov_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
> 2021 to March 31, 2021
> Message-ID: <144201d72239$0c182c30$24488490$@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 26 Mar 2021 14:19:24 +0200
> From: "Peter Dimov" <pdimov_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID: <144401d7223a$42e76ef0$c8b64cd0$@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Andrzej Krzemienski wrote:
> > 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.
>
> I'll add the shift operators and the unary * at minimum, will see about any
> others. The current set is determined by the function objects in
> <functional>.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 26 Mar 2021 20:50:52 +0530
> From: prince raj <sdavil318_at_[hidden]>
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Subject: [boost] To contact project's mentor for GSoC21
> Message-ID: <B9EC3FCE-61E8-47E7-8665-FFFE6088824F_at_hxcore.ol>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> Hello,
>
>
> My self Anish Kumar Singh and I want to participate to in boost
> organisation.
>
> But I have no idea how to contact mentor for project discussion and my
> ideas with him.
>
> So please help me contacting to mentor so that I can make my proposal
> good to summit.
>
>
> Thankyou...
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 26 Mar 2021 12:46:26 -0300
> From: Vin?cius dos Santos Oliveira <vini.ipsmaker_at_[hidden]>
> To: Boost <boost_at_[hidden]>
> Cc: prince raj <sdavil318_at_[hidden]>
> Subject: Re: [boost] To contact project's mentor for GSoC21
> Message-ID:
> <
> CAK9RveLeh66nHX-ZBRpPs4mP+fDZ5JjwN3beVVRd8X0dnHCvRA_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Em sex., 26 de mar. de 2021 ?s 12:22, prince raj via Boost <
> boost_at_[hidden]> escreveu:
>
> > But I have no idea how to contact mentor for project discussion and my
> > ideas with him.
> >
>
> What's the project you're interested in?
>
>
> --
> Vin?cius dos Santos Oliveira
> https://vinipsmaker.github.io/
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 26 Mar 2021 17:32:14 +0100
> From: Mateusz Loskot <mateusz_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] To contact project's mentor for GSoC21
> Message-ID:
> <
> CABUeae8fsFiX6CS6_HXH-u59_GQJscbEdEJEZ-W0naq_WJRHiA_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 26 Mar 2021 at 16:22, prince raj via Boost
> <boost_at_[hidden]> wrote:
> >
> > But I have no idea how to contact mentor for project discussion and my
> > ideas with him.
> >
> > So please help me contacting to mentor so that I can make my proposal
> > good to summit.
>
> First, read this and the materials linked there
> https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 26 Mar 2021 19:45:39 -0700
> From: Christian Mazakas <christian.mazakas_at_[hidden]>
> To: "boost_at_[hidden] List" <boost_at_[hidden]>
> Cc: Peter Dimov <pdimov_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID:
> <
> CAHf7xWsqNHEt8-nxBRFz1+BjNMiwXasoYsFOuFR+tpd2EWZkog_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 26 Mar 2021 23:18:47 -0700
> From: Emil Dotchevski <emildotchevski_at_[hidden]>
> To: Boost <boost_at_[hidden]>
> Subject: Re: [boost] [Boost] [Lambda2] Review starts Monday March 22,
> 2021 to March 31, 2021
> Message-ID:
> <CAN5fK5HJmHeZOoQ-nYwrHxKnQMjcAX8bLR4KMKz3=
> QsXwrM-Pw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Here is my review of lambda2:
>
> I remember when I first learned boost::bind, and realized how much more
> useful STL is because of it. Even after C++11 I still find myself using
> bind, it sometimes looks more readable to my eyes than a lambda.
>
> The lambda2 library is one more proof for the solid design behind
> std::bind. That, or std::bind was designed with things like lambda2 in
> mind. Either way, lambda2 is an elegant utility for writing elegant C++,
> albeit only in the (rare?) cases when it is a perfect fit. Given this, and
> the miniature size of the library, my vote is to ACCEPT.
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 27 Mar 2021 17:42:36 +0000
> From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID: <1616866956454_at_[hidden]>
> Content-Type: text/plain; format="flowed"; charset="UTF-8"
>
> 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 ?
>
> 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.)
>
>
> Regards, Phil.
>
>
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Sat, 27 Mar 2021 19:58:03 +0200
> From: "Peter Dimov" <pdimov_at_[hidden]>
> To: <boost_at_[hidden]>
> Subject: Re: [boost] [Lambda2] Review starts Monday March 22, 2021 to
> March 31, 2021
> Message-ID: <14fe01d72332$bc76fad0$3564f070$@gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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. :-)
>
>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 27 Mar 2021 22:38:36 +0530
> From: sayan chaudhuri <sayanchaudhuri758_at_[hidden]>
> To: boost_at_[hidden]
> Subject: [boost] [Boost][GIL][GSOC 2021] Contribute to the library
> Message-ID:
> <CAJH=
> o2N_rOMqaPg+jt823+Nj9Z+fD+w-4LqQw8ZOOBkEUMAUzw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello Everyone,
> My name is Sayan Chaudhuri. I am a final
> year,undergraduate student,in the Computer Science and Engineering
> department of IEM,India . I am eager to participate in the GSOC 2021 and
> willing to contribute to the Boost GIL library.
> I have already gone through the wiki list of Boost
> GIL listing the various image processing and computer vision algorithms
> that have not been implemented yet. I have also gone through the
> Contributing documents for BOOST GIL. . While going through the Boost
> Mailing List Archives, I found that Igor Antropov had suggested to develop
> ORB descriptor during his GSOC tenure but it has not been implemented yet..
> I am therefore eager to develop the ORB descriptor for Boost GIL during
> GSOC 2021. ORB is useful in many situations like object recognition and
> structure for motion and also it is suitable for real time applications
> unlike SIFT and SURF. I also found out that while using Boost , everytime I
> need to see the output , I need to save the output in order to view
> it,thereby unnecessarily wasting memory when I do not wish to save the
> output. So, the functionality of imshow() for OPENCV is missing for Boost
> GIL. I am also eager to work on that functionality as well during GSOC
> 2021. Would therefore anyone is interested in mentoring me?
> As my programming competency test for Boost GIL, I
> have implemented the KMeans algorithm from scratch using Boost GIL and I
> have raised a pull request- https://github.com/boostorg/gil/pull/587. I
> would kindly request if someone can kindly review it. Also, I would like to
> know whether there are any similar issues that I can work on currently.
>
>
> ------------------------------
>
> Message: 11
> Date: Sun, 28 Mar 2021 03:22:35 +0000
> From: Suraj Nehra <surajnehra112_at_[hidden]>
> To: boost_at_[hidden]
> Subject: [boost] (no subject)
> Message-ID:
> <CAJR02FfuUhWpDYveadts9Xd5QD5_tzV5z=
> hgMmar1greSBmzSw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
> I am Suraj Nehra, a pre-final year student at the National Institute of
> Technology (NIT), Warangal, India. This mail is to introduce myself to the
> boost community. Boost.Real is not added to boost project ideas page yet
> but I was discussing ideas with Vikram(vikram2000b_at_[hidden]) and also
> made
> several contributions to the library.
>
> I wish to work on this library in this GSoC and will start drafting
> the proposal. I received the competency task from Vikram and will start
> working on those. I was informed of the following potential ideas by him:
> 1. Library comparison and benchmarking with other similar libraries.
> 2. DAG internal representation
> 3. Propose and implement optimizations for trigonometric functions.
>
> I wish to work on ideas 1 and 3. I will start making the proposal for these
> ideas and share the draft with you.
> It will be a pleasure to hear any suggestions and guidance from you.
>
> Thanks & Regards
> Suraj Nehra
>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 28 Mar 2021 03:30:54 +0000
> From: Suraj Nehra <surajnehra112_at_[hidden]>
> To: boost_at_[hidden]
> Subject: [boost] [GSoC] Boost.Real: Introduction and Guidence
> Message-ID:
> <
> CAJR02Fe4w-FfDcjDK4NfLs1LNqBwThi5uxF-nhefMo6NhrSSkw_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
> I am Suraj Nehra, a pre-final year student at the National Institute of
> Technology (NIT), Warangal, India. This mail is to introduce myself to the
> boost community. Boost.Real is not added to boost project ideas page yet
> but I was discussing ideas with Vikram(vikram2000b_at_[hidden]) and also
> made
> several contributions to the library.
>
> I wish to work on this library in this GSoC and will start drafting
> the proposal. I received the competency task from Vikram and will start
> working on those. I was informed of the following potential ideas by him:
> 1. Library comparison and benchmarking with other similar libraries.
> 2. DAG internal representation
> 3. Propose and implement optimizations for trigonometric functions.
>
> I wish to work on ideas 1 and 3. I will start making the proposal for these
> ideas and share the draft with you.
> It will be a pleasure to hear any suggestions and guidance from you.
>
> Thanks & Regards
> Suraj Nehra
>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 28 Mar 2021 09:54:11 +0300
> From: Antony Polukhin <antoshkka_at_[hidden]>
> To: "boost_at_[hidden] List" <boost_at_[hidden]>
> Subject: [boost] Changelog for 1.76 is outdated
> Message-ID:
> <
> CAKqmYPazb_JKWwwy-DZGdpfseJ4wB0KXR3FsK22o-nZ0w6G+0Q_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> The https://www.boost.org/users/history/version_1_76_0.html seems quite
> outdated. Please update
>
> Thanks in advance!
>
>
> ------------------------------
>
> Message: 14
> Date: Sun, 28 Mar 2021 09:56:43 +0300
> From: Antony Polukhin <antoshkka_at_[hidden]>
> To: "boost_at_[hidden] List" <boost_at_[hidden]>
> Subject: Re: [boost] Changelog for 1.76 is outdated
> Message-ID:
> <CAKqmYPaXN-c=
> k45pCMWVDYAdHX+p916H2fjkfHXZ4pvVchRV6A_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> By "outdated" I mean that
>
> https://github.com/boostorg/website/blob/master/feed/history/boost_1_76_0.qbk
> has more info
>
>
> ------------------------------
>
> Message: 15
> Date: Sun, 28 Mar 2021 15:05:07 +0200
> From: shady mohamed <shadimabdrawy1999_at_[hidden]>
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost Digest, Vol 6566, Issue 1
> Message-ID:
> <
> CAPwR5ipUjbt4R5E_W4qO3wvfkm7NfmiT1Q99AhMwWvGxTUyk2A_at_[hidden]>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> > **************************************
> >
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> ------------------------------
>
> End of Boost Digest, Vol 6567, Issue 1
> **************************************
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk