[wwright]

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

[klipt]

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.

[SamReidHughes]

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

[dkersten]

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?

[Rusky]

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.

[dkersten]

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?

[Rusky]

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.

[MauranKilom]

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));

[edflsafoiewq]

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.

[Rusky]

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.)

[edflsafoiewq]

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.

[Filligree]

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

[Rusky]

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.

[steveklabnik]

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”.

[likeliv]

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.

[steveklabnik]

“Early drop”, thanks autocorrect.