Rust has the exact same semantics there. Drop is useful when you need to explicitly notate that a value should end its life early.

void drop(unique_ptr<T>&& x) {}

Would do the same in C++ for values held by unique_ptr: take ownership of the pointer and then free it.

No, it would not free it. It takes a reference to the pointer and does nothing.

unique_ptr disposes of the object its holding when it goes out of scope unless passed to another unique_ptr or ownership is explicitly released. Presumably klipt would std::move the unique_ptr, hence the universal reference (which seems unnecessary, just pass it by value).

Am I missing something? Does it not work with std::move?

Yes, you're missing that the type `T&&` is a reference, not a value, and so does not run the object's destructor when it goes out of scope.

Sorry, I edited right after hitting reply to clarify that I'm assuming the intention was to std::move the unique_ptr in, since it was T&& and not T&. Would that still not work?

It would still not work. All std::move does is cast to T&&, enabling overload resolution to pick a function with T&& as its parameter type.

Thanks for explaining!

It would have to be

void drop(std::unique_ptr<T> x) {}

Or, you know, just call someX.reset(); or do someX = nullptr;. The drop call would be way noisier: drop(std::move(someX));

The equivalent to drop in C++ would be

    template <class T>
    void drop(T&) = delete; // force callers to move

    template <class T>
    void drop(T&& x) {
        T drop_me(std::move(x));
    }

edit: fixed.

This is not correct; moves must leave the value in a valid state, because its destructor will still run. The correct version is actually the same as Rust's:

    template <class T>
    void drop(T) {}

(Moving into a local in `drop(T&&)` also works.)

You're correct, sorry (I did have that at one point...). But the equivalent of Rust's pass-by-moving is to pass an r-value reference. Passing a const reference to drop is certainly an error and should be disallowed.

It used to, they got subtler. See https://stackoverflow.com/questions/50251487/what-are-non-le...

NLL does not change those semantics; drop still runs at the end of the scope. It counts as a "use" for the purposes of NLL and thus keeps values with destructors alive.

For some history, it was talked about changing this, but we couldn’t, due to back compatibility and it wasn’t clear it was actually a good idea. This was called “wary drop”.

Would be nice if types could annotate their Drop trait with #[early_drop] if the drop has no visible side effect, do rust could free the memory earlier.

“Early drop”, thanks autocorrect.

Tell that to the enormous heap object you just forgot you made earlier.

It would work with an object held by unique_ptr though, exactly like this Rust example.

You’re not using std::unique_ptr to manage that?