$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Fit] formal review starts today
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-03-03 19:43:58
Steven Watanabe <watanabesj <at> gmail.com> writes:
> 
> AMDG
> 
> On 03/03/2016 04:43 AM, Vicente J. Botet Escriba wrote:
> > Dear Boost community, sorry for the late announce
> > 
> > The formal review of Paul Fultz II's Fit library starts today, 2nd March
> > and ends on 13th March.
> > 
> [...]
> 
> 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. The only case where it can 
be harmful is if one "saves" the result of `fit::capture`, which could lead 
to (arguably ugly) dangling reference bugs:
    auto some_function() {
        std::string s = "foobar";
        // oops, the return value contains a dangling reference to `s`
        return fit::capture(s)(f); 
    }
However, this should rarely happen. Of course, one could also suggest that
instead of defaulting to capture-by-reference, the desire to capture by 
reference could be stated explicitly by using `std::ref` or some similar
mechanism:
    fit::capture(std::ref(variables)...)(f)
I'm not sure what's the best solution. 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.
Regards,
Louis Dionne