How to do type conversion on an "implicit" rvalue in the return statement

user_1329652 0
Viewed 78

Is this invalid? gcc accepts it, clang and msvc don't.

#include <memory>

class Holder {
    std::unique_ptr<int> data;
public:
    operator std::unique_ptr<int>() && { return std::move(data); }
};

std::unique_ptr<int> test()
{
    Holder val;
    return val;
}

Assuming that I don't want to add something like std::unique_ptr<int> Holder::TakeData() { return std::move(data); }, the only other workaround I could think of is moving in the return value:

std::unique_ptr<int> test()
{
    Holder val;
    return std::move(val); // lets the conversion proceed
}

But then gcc 9.3+ has the gall to tell me that the std::move is redundant (with all warnings enabled). WTF? I mean yeah, gcc doesn't need the move, sure, but nothing else accepts the code then. And if it won't be gcc, then some humans inevitably will balk at it later.

  1. What's the authoritative last word on whether it should compile as-is or not?
  2. How should such code be written? Should I put in this seemingly noisy TakeData function and use it? Worse yet - should I maybe make the TakeData function limited to rvalue context, i.e. having to do return std::move(val).TakeData() ?

Adding operator std::unique_ptr<int>() & { return std::move(data); } is not an option, since it obviously leads to nasty bugs - it can be invoked in wrong context.

language-lawyer c++
1 Answers

The "implicit" rvalue conversion is standard mandated. But depending on which standard version you are using, which compiler is "correct" varies.

In C++17

[class.copy.elision] (emphasis mine)

3 In the following copy-initialization contexts, a move operation might be used instead of a copy operation:

  • If the expression in a return statement is a (possibly parenthesized) id-expression that names an object with automatic storage duration declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, or

  • ...

overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If the first overload resolution fails or was not performed, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue. [ Note: This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor to be called if elision is not performed, and the selected constructor must be accessible even if the call is elided.  — end note ]

Up to C++17, GCC is wrong. Using val implicitly as an rvalue should fail to initialize the return type on account of the sentence I marked in bold (the rvalue reference in the unique_ptr c'tor doesn't bind directly to val). But come C++20, that sentence is no longer there.

C++20

3 An implicitly movable entity is a variable of automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type. In the following copy-initialization contexts, a move operation might be used instead of a copy operation:

  • If the expression in a return ([stmt.return]) or co_­return ([stmt.return.coroutine]) statement is a (possibly parenthesized) id-expression that names an implicitly movable entity declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, or

  • [...]

overload resolution to select the constructor for the copy or the return_­value overload to call is first performed as if the expression or operand were an rvalue. If the first overload resolution fails or was not performed, overload resolution is performed again, considering the expression or operand as an lvalue. [ Note: This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor or the return_­value overload to be called if elision is not performed, and the selected constructor or return_­value overload must be accessible even if the call is elided. — end note ]

The correctness of the code is thus subject to the time travel properties of your compiler(s).

As far as how should code like that should be written. If you aren't getting consistent results, an option would be to use the exact return type of the function

std::unique_ptr<int> test()
{
    Holder val;
    std::unique_ptr<int> ret_val = std::move(val);
    return ret_val;
}

I agree from the get go that this may not look as appealing as simply returning val, but at least it plays nice with NRVO. So we aren't likely to get more copies of unique_ptr than we desired originally.

If that is too unappealing still, then I find your idea of a resource stealing member function to be most to my liking. But no accounting for taste.

user_8176430
Related