Boost logo

Boost :

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>> writes:

> 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


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.

Louis Dionne

Boost list run by bdawes at, gregod at, cpdaniel at, john at