Why std::optional::value() &&; return &&?

Question

I have had runtime error, when replaced some code by using std::optional:

Old code:

T getValue();
...
const auto& value = getValue();
value.get();

New code:

std::optional<T> getValue();
...
const auto& value = getValue().value();
value.get(); // Runtime error, crash 

It was unpredictable for me. The reason of crash is that the method returns T&&.

My question is in what cases T&& can be useful, why the method does not return a T.

Complete code:

#include <experimental/optional>
#include <iostream>
#include <memory>

struct Value {
    std::unique_ptr<int> a = std::make_unique<int>(5);
};

std::experimental::optional<Value> getValue() {
    Value v;
    return v;
}

int main() {
    const Value& value = getValue().value();
    std::cout << *value.a << std::endl;
    return 0;
}

Answer 1

It is a minor design flaw caused by two competing needs.

First, avoiding extra moves, and second enabling reference lifetime extension.

These two compete in current C++; you usually cannot solve both problems at once. So you will see code doing one or the other, quite haphazardly.

I personally find returning an rvalue reference to generate more problems than moving from a soon to be destroyed object, but those who standardized std::optional disagreed.

My preferred solution would have other downsides.

To fix this—to not have to make these compromises—we would require a complex messy redefinition of how lifetime extension works. So we have to live with these problems for now.

Answer 2

Returning T forces to move construct it, whereas returning (rvalue-)reference has no cost.

Let suppose that you have

std::optional<std::array<T, N>> getOptional();

then

getOptional().value()

would do several copies (RVO doesn't apply here as it would return a (moved) member).