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.