c++lambdatemporary-objectsforwarding-reference

Lambda capturing rvalue reference by reference


Is below code standard-correct? (godbolt)

I.e. by-ref capturing a forwarding reference that represents a temporary, and returning the resulting lambda by-value from the function, within the same expression.

Of course storing the lambda for later use would make it contain a dangling reference, but I'm referring to the exact usage inside main.

The doubts I'm having relate to this SO answer and potentially this language defect. Specifically there is one daunting comment that says "the reference capture lifetime rule in the standard references captured variables, not data, and their scope" - this appears to say a captured reference to a temporary might be invalid in my code.

#include <stdlib.h>
#include <string.h>
#include <cassert>

template<typename F>
auto invoke(F&& f)
{
    return f();
}

template<typename F>
auto wrap(F&& f)
{
    return [&f]() {return f();}; // <- this by-ref capture here
}

int main()
{
    int t = invoke(wrap(
        []() {return 17;}
    ));

    assert(t == 17);
    return t;
}

Solution

  • There was UB in your code for a relatively short historical time window. (Note: this is a very strange thing to say). The original lambda capture-by-reference rules stated the reference was only valid until the variable captured went out of scope.

    There is no UB in your code under both the current standard, and under every retroactively revised past standards.

    This could lead to a sort of capture reference-by-reference, otherwise impossible in the C++ standard. (The closest you could get would be a reference to a one-member struct containing a reference)

    In theory, you could use that fact to make lambda reference capture be stack-frame based; capture the current stack frame, and all (almost?) by-reference arguments would be at fixed offsets to that stack frame.

    As most (all?) ABIs implement reference arguments as pointers under the hood, this would lead to reference arguments to functions arguments which are references dangling after the lambda returned.

    No compiler exploited this fact. That optimization was never used, it was just observed as possible. The "reference capture of a lambda has a lifetime of the variable reference" rule was never exploited by any compiler (or at least any I heard of).

    When it was spotted, it was resolved as a defect resolution in the standard, which means it retroactively redefined what meant.

    So while under historical compiler this was technically UB, no current compliant compiler can treat it as UB, and all historical C++11 compilers treat it the same way current compilers do. So you are safe.