Why can't I bind a const lvalue reference to a function returning T&&?

Question

I was binding some return value of a function to a const lvalue reference, but the object was deleted, before the lifetime of the const lvalue reference ended.

In the following example the Foo object is destroyed before the lifetime of foo ends:

#include <iostream>
#include <string>

struct Foo
{
    ~Foo()
    {
        std::cout << "Foo destroyed: " << name << std::endl;
    }
    std::string name;
};

Foo&& pass_through(Foo&& foo)
{
    return std::move(foo);
}

int main()
{
    const Foo& foo = pass_through({"some string"});
    std::cout << "before scope end" << std::endl;
}

The output is:

Foo destroyed: some string
before scope end

live on coliru: 1

I thought you can bind const T& to anything. Is it bad practice to return T&& and should returning by value be preferred?

I stumbled across this in the cpprestsdk here:

inline utility::string_t&& to_string_t(std::string &&s) { return std::move(s); }

https://github.com/Microsoft/cpprestsdk/blob/master/Release/include/cpprest/asyncrt_utils.h#L109

Very confusing, because the windows version of to_string_t (dispatched by preprocessor macros) returned by value:

_ASYNCRTIMP utility::string_t __cdecl to_string_t(std::string &&s);

Edit: Why does it work when passing the result of pass_through to a function taking const Foo&? The lifetime is extended in this case?

What

too early in the morning to think, but the explicit destructor may prevent the move constructor from being implicitly created. en.cppreference.com/w/cpp/language/move_constructor – Belleslettres

Lifetime extension only applies when the reference binds directly to a temporary. – Ulrike

@KennyOstrom I tried with explicitly generating the default move constructor via Foo(Foo&&) = default; and it produced the same result. – What

Why would the lifetime of a foo-reference exceed the line const Foo& foo = pass_through({"some string"}); ? – Aphra

Imagine if you only had the declaration of pass_through() available. There's no way to know there's a link between the parameter RValue ref and the result RValue ref, and the lifetime of the temporary Foo must still be resolved at compile time, so the compiler has no choice but to be pessimistic about it. – Aftonag

You can pass it as an argument because the lifetime of a temporary lasts until the end of the "full-expression" it's created in. (Very informally, "until the next semicolon".) No extension is necessary. – Utilitarianism

@Pi -- in const Foo& foo = Foo(): the lifetime of the temporary object created by Foo() is extended, so it remains valid as long as foo does. That's called "lifetime extension". This question involves creating a temporary Foo object indirectly, and, as comments have said, that doesn't result in lifetime extension. – Vitiated

Static analysis ought to be able to detect this, I predict we will see compilers able to warn about this in future – Troth

Answer 1

From the standard:

15.2 Temporary objects

6.9 A temporary object bound to a reference parameter in a function call persists 
    until the completion of the full-expression containing the call.

Essentially what it's saying is that because you passed in a temporary object and then didn't extend its lifetime (say, by moving it into an lvalue) then its lifetime only lasts until the first ; after the call to pass_through in your code. After this point you are left with foo as a dangling reference.

int main()
{
    const Foo& foo = pass_through({"some string"}); // "some string" lifetime ends here
    std::cout << "before scope end" << std::endl;
}

As to whether it is good practice to to return an rvalue reference I believe these two answers already go into detail on the subject:

Should I return an rvalue reference parameter by rvalue reference?

Is returning by rvalue reference more efficient?

Photomicrograph