Returning unique_ptr<Object> as unique_ptr<const Object>

Question

I have a method like this:

std::unique_ptr<const Stats> Table::GetStats() const {
  std::unique_ptr<Stats> result;
  // ...
  // Prepare stats. Under some conditions an exception may be thrown.
  // ...
  return result;
}

The problem is that it doesn't compile:

error: cannot bind ‘std::unique_ptr’ lvalue to ‘std::unique_ptr&&’

I can make it compile by using the following bypass:

return std::unique_ptr<const Stats>(result.release());

But it seems a bit as doing something excessive. I cannot understand, what's wrong with the first piece of code from C++'s point of view? Is there more elegant solution?

Answer 1

Your code should work fine, because in return statement:

(emphasis mine)

(since C++11)

If expression is an lvalue expression and the conditions for copy elision are met, or would be met, except that expression names a function parameter, then overload resolution to select the constructor to use for initialization of the returned value is performed twice: first as if expression were an rvalue expression (thus it may select the move constructor or a copy constructor taking reference to const), and if no suitable conversion is available, overload resolution is performed the second time, with lvalue expression (so it may select the copy constructor taking a reference to non-const).

The above rule applies even if the function return type is different from the type of expression (copy elision requires same type)

That means, even result is an lvalue, it'll be regarded as an rvalue at first, then the following constructor would be selected, it could convert std::unique_ptr<Stats> to std::unique_ptr<const Stats>.

template< class U, class E >
unique_ptr( unique_ptr<U, E>&& u ) noexcept;

It seems gcc4.9.2 doesn't behave this way (i.e. treating the expression as an rvalue expression firstly); gcc 9 just works fine.

As @RichardHodges commented, you could use std::move as the workaround.