A wrapper to inhibit compiler from automatically calling T’s destructor.

This wrapper is 0-cost.

ManuallyDrop<T> is subject to the same layout optimizations as T.
As a consequence, it has no effect on the assumptions that the compiler makes
about all values being initialized at their type. In particular, initializing
a ManuallyDrop<&mut T> with mem::zeroed is undefined behavior.
If you need to handle uninitialized data, use MaybeUninit<T> instead.

This wrapper helps with explicitly documenting the drop order dependencies between fields of
the type:

usestd::mem::ManuallyDrop;
structPeach;
structBanana;
structMelon;
structFruitBox {
// Immediately clear there’s something non-trivial going on with these fields.peach: ManuallyDrop<Peach>,
melon: Melon, // Field that’s independent of the other two.banana: ManuallyDrop<Banana>,
}
implDropforFruitBox {
fndrop(&mutself) {
unsafe {
// Explicit ordering in which field destructors are run specified in the intuitive// location – the destructor of the structure containing the fields.// Moreover, one can now reorder fields within the struct however much they want.ManuallyDrop::drop(&mutself.peach);
ManuallyDrop::drop(&mutself.banana);
}
// After destructor for `FruitBox` runs (this function), the destructor for Melon gets// invoked in the usual manner, as it is not wrapped in `ManuallyDrop`.
}
}

This function semantically moves out the contained value without preventing further usage,
leaving the state of this container unchanged.
It is your responsibility to ensure that this ManuallyDrop is not used again.

This function runs the destructor of the contained value and thus the wrapped value
now represents uninitialized data. It is up to the user of this method to ensure the
uninitialized data is not actually used.
In particular, this function can only be called at most once
for a given instance of ManuallyDrop<T>.