Re: [boost] [Fit]Â formal review starts today

Subject: Re: [boost] [Fit] formal review starts today
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-03-04 16:15:45

On Friday, March 4, 2016 at 1:05:39 PM UTC-6, Vicente J. Botet Escriba 
wrote:
>
> Le 04/03/2016 19:59, Vicente J. Botet Escriba a écrit : 
> > Le 04/03/2016 18:26, Paul Fultz II a écrit : 
> >> 
> >> On Thursday, March 3, 2016 at 8:14:30 PM UTC-6, Steven Watanabe wrote: 
> >>> AMDG 
> >>> 
> >>> On 03/03/2016 05:43 PM, Louis Dionne wrote: 
> >>>> Steven Watanabe <watanabesj <at> gmail.com> writes: 
> >>>> 
> >>>>> On 03/03/2016 04:43 AM, Vicente J. Botet Escriba wrote: 
> >>>>> capture.hpp: 
> >>>>> 
> >>>>> 32: // Capture lvalues by reference and rvalues by value. 
> >>>>>      The default should be to capture everything by value. 
> >>>>>      Capturing by reference is potentially dangerous, and 
> >>>>>      switching based on whether the argument is an lvalue 
> >>>>>      is even more so. 
> >>>> I've implemented the same thing in Hana, so I had to make the same 
> >>> design 
> >>>> decision as Paul did at some point. I decided to be consistent with 
> >>>> the 
> >>> rest 
> >>>> of Hana, which is to capture by value. 
> >>>> 
> >>>> However, I am not sure that my decision in Hana was a wise one, and 
> >>>> I am 
> >>>> tempted to think that Paul's solution is actually the right one. 
> >>>> Indeed, 
> >>>> in most cases, `fit::capture` will be used as a temporary: 
> >>>> 
> >>>>      some_alogrithm(..., fit::capture(variables...)(function)); 
> >>>> 
> >>>> In this case, capturing by reference is harmless. <snip> Basically, 
> my 
> >>> point is simply that 
> >>>> saying "you should always capture by value" is naive in this context. 
> >>>> Perhaps you're right, perhaps you're wrong, but in all cases this 
> >>>> design 
> >>>> choice is not an obvious one, at least not to me. Just my .02. 
> >>>> 
> >>>    You have a point, and perhaps capturing by 
> >>> reference makes sense.  In fact, lambdas 
> >>> do capture by reference by default, so 
> >>> there is precedent for it.  I do maintain, 
> >>> however, that choosing whether to capture 
> >>> by value based on l/r-valueness is definitely 
> >>> wrong. 
> >>> 
> >> Why is that wrong? Furthermore the name was chosen not for it to be 
> >> default 
> >> but based on the transformations it makes to the type categories. 
> >> 
> >> - capture_decay: 
> >>           Transform each category using decay 
> >> 
> >> - capture_forward: 
> >>           Transform each category to a reference. So that means 
> >> rvalues become 
> >>      references. 
> >> 
> >> - capture: 
> >> 
> >>      Dont transform the type category. Lvalues are captured as 
> >> lvalues and 
> >>      rvalues are captured as rvalues. 
> >> 
> >> Furthermore, capturing rvalues by rvalue instead of reference helps 
> >> improve 
> >> safety, because rvalue references do not always extend the lifetime of 
> a 
> >> temporary. 
> >> 
> > What is the rational to capture all the same way? 
> > Why not have something like std::ref to change the way? 
> > 
> > 
> If we consider that by default we capture by reference, can we capture a 
> specific parameter by value? 
>

Well, you would need to create some kind of value_wrapper(like
reference_wrapper). Although, I would prefer not to have that much "magic"
happen. If you want an lvalue, give it an lvalue, if you want an rvalue, 
give
it an rvalue. Plus, the standard C++ language can be used to manipulate the
type categories rather than relying on "magical" wrappers.