Tracking issue for drop_in_place

[Gankra]

This calls the "drop glue" for a given type without having to explicitly read it out onto the stack to be dropped. All types have a drop glue implementation, which involves calling the types Drop impl (if it exists), and the recursively running drop glue on its fields.

drop_in_place is both a performance improvement (in the case of e.g. Vec, it avoids ptr::reading the elements out), and a semantic necessity (in the case of DSTs, it's impossible to ptr::read the value, but the vtable always contains a drop glue impl).

It is currently exposed in the ptr module because it's maximally expressive to take a *mut and because "that's what the intrinsic took" at the time it was exposed outside of std::intrinsics. It may be desirable to instead expose it in mem to parallel mem::drop, and require an &mut. For most cases you probably already have an &mut anyway, and it's trivial to upgrade.

[Marwes]

Are there any plans to stabilize this?

[Gankra]

@nagy24 it seems your message got garbbled up?

[arielb1]

This won't really work with &mut because it will leave it pointing to an invalid value.

[Gankra]

@arielb1 it would definitely have to be unsafe. Making the value invalid isn't necessarily a problem unless you're picturing more advanced analysis. I do kind've like the idea of a convention where invalidating ops are only exposed on raw pointers, though.

[alexcrichton]

🔔 This issue is now entering its cycle final comment period to be stabilization in 1.8 🔔

The libs team is somewhat up in the air about whether this function should take *mut T vs &mut T. If it were to take &mut T it would be in the mem module instead of the ptr module.

One one hand this method is only actually safe to call if you have a valid unique reference (e.g. &mut T). On the other hand, however, the reference is immediately invalid to use right after the call.

We're curious if others have opinions!

[KalitaAlexey]

Is there a lint to warn about use after drop?

[Marwes]

Since drop and forget is in the mem module I would argue for drop_in_place to be there as well. Even though it is an unsafe intrinsic instead of a safe convenience function it still interacts with the Drop trait just as drop and forget does. On the other hand the ptr module only indirectly interacts with Drop.

For the choice between &mut and *mut I have less of an opinion. I were going to say that there are already Drop implementations that invalidate the &mut self pointer but I couldn't actually think of a case where this happens. Virtually all Drop implementations have a *mut which their memory is allocated behind which becomes invalid but the &mut self itself pointer is always valid for types such as Vec, HashMap etc.

[alexcrichton]

@KalitaAlexey not currently, no.

@Marwes perhaps yeah, although the placement of mem vs ptr today currently just largely has to do with the types of the arguments (e.g. raw pointers or "safe" values). Basically if we stabilize with *mut T it would be unconventional to place it in the mem module (and vice versa if we stabilize with &mut T).

My thinking for using a raw pointer is that if you're calling drop_in_place you're pretty unlikely to have a safe mutable pointer to the data in the first place anyway. For example the Rc and Arc both have to go through a *mut RcBox<T> to get at the underlying value.

[briansmith]

This calls the "drop glue" for a given type without having to explicitly read it out onto the stack to be dropped.

Why not change how drop is optimized to avoid the copy? It seems such an optimization is needed by many things.