Why does std::optional::value_or() take a U&& rather than T&&?

Question

On cppreference, we can see std::optional takes a default value of U&& rather than T&&.

It makes me incapable of writing the following code:

std::optional<std::pair<int, int>> opt;
opt.value_or({1, 2}); // does not compile
opt.value_or(std::make_pair(1, 2)); // compiles

However, I find there is no benefit to using U&&, since U must be convertible to T here.

So, consider the following code, if we have some type U which differs from T, then there will be no perfect match. However, by performing an implicit cast, we can still resolve our call:

template< class U >
constexpr T value_or( T&& default_value ) const&;

I have the following code to test if a template function can take an argument which needs an extra implicit casting to make a perfect match, and it compiles:

#include <cstdio>
#include <optional>
#include <map>

struct A {
    int i = 1;
};

struct B {
    operator A() const {
        return A{2};
    }
};

template <typename T>
struct C {
    void f(T && x) {
        printf("%d\n", x.i);
    }
};

int main() {
    auto b = B();
    C<A> c;
    c.f(b);
}

Answer 1

I find there it no benefit by using U&&, since U must be convertible to T here.

U must be convertible to T, but a conversion can be expensive. Taking a forwarding reference (U&&) avoids performing that conversion if the argument is not used (if the object contains a value).

The same cppreference page says value_or is equivalent to:
bool(*this) ? **this : static_cast<T>(std::forward<U>(default_value)).
Here, static_cast<T> performs the conversion, but it is only performed if bool(*this) is false.

Answer 2

It is to allow perfect forwarding. If the signature were

constexpr T value_or( T&& default_value ) const&;

then T is not something that will be deduced, it is known from the class instantiation, meaning T&& default_value is just a plain rvalue reference to whatever T is.

By using

template< class U >
constexpr T value_or( U&& default_value ) const&;

The U needs to be deduced making it a forwarding reference.

Answer 3

As a concrete example

template<class T>
struct constructor {
  operator T()const{
    return f();
  }
  std::function<T()> f;
  constructor( std::function<T()> fin = []{return T{};} ):
    f(std::move(fin))
  {}
};
template<class F>
constructor(F) -> constructor<std::invoke_result_t<F>>;

Now I have an std::optional<std::vector<int>> bob;. I can do:

auto v = bob.value_or( constructor{ []{ return std::vector<int>(10000); } } );

here, if bob has a value, we return it. Otherwise, we create a 10,000 element vector and return that.

Because we defer the conversion from U&& to T for the false branch, we don't have to allocate the 10,000 sized vector unless we need to return it.

Now, I find that adding a T&& overload in these cases is well worth it, and the standard library doesn't do it enough, mostly for the reason you describe -- it permits {} based construction.