Tracking issue for ManuallyDrop

[alexcrichton]

Tracking issue for rust-lang/rfcs#1860

I believe initially implemented at #40559

[Ericson2314]

I left a comment rust-lang/rfcs#1860 (comment) which slipped by FCP. The tl;dr is: this is fine for now in my book, but we should consider &move and improved Drop again prior to stabilization. I'd hope the popularity of this feature would be considered a +1 &move---a wholly nicer, if harder-to-implement, solution---rather than a -1 (with the reasoning that this trick is good enough so &move isn't needed).

[SimonSapin]

I’d like this to be stabilized. What’s the next step?

The only alternative that I know of is https://crates.io/crates/nodrop, which on stable Rust requires a combination of hacks that look fragile to me.

[crumblingstatue]

I am personally using this in a project, so I'm in favor of stabilizing a solution for specifying drop order, but I also don't want @Ericson2314's comment ignored before stabilizing this.

[sfackler]

I don't believe &move or a new Drop are anywhere near the horizon. It seems unreasonable to hold this API up indefinitely.

@rfcbot fcp merge

[rfcbot]

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams:

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @brson
• @dtolnay
• @sfackler

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[dtolnay]

I filed rust-lang-nursery/api-guidelines#93 to follow up with a justification of why we prefer into_inner(ManuallyDrop<T>) over into_inner(self).

@rfcbot reviewed

[Ericson2314]

Fair enough, this can always be deprecated.

[SimonSapin]

@brson I think this is waiting on you :)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[Gankro]

Hey nice I was about to propose stabilizing this. 🎉

[bluss]

Sorry if I have missed this somewhere — do we have a decision for how layout optimization handles things like Option<ManuallyDrop<&i32>>? I can see that right now, the inner value is not used for the discriminant.

[SimonSapin]

In the case of struct ArrayVec<A: Array> { length: usize, data: ManuallyDrop<A> } impl<T, N: usize> Array for [T; N] {…} (assuming integer generics, or with a macro to generate impls for a number of specific N values), it is important that e.g. Option<ArrayVec<[&i32; 16]>> does not use the nonzeroness of &i32 to represent the discriminant of Option because the &i32 items might be uninitialized.

Or, in other words, ArrayVec needs some way to inhibit propagation of enum layout optimizations, and ManuallyDrop could be it.

[ldr709]

This is probably neither the right time nor place for this, but any plans to impl Copy? It may seem odd to do so, since Copy types can be dropped trivially, but this would be useful in situations where you don't know whether or not a type impls Copy.

[Gankro]

You can submit a PR to derive(Copy) and it will likely be accepted.

[kjetilkjeka]

When testing it seems like impl<T: Clone> for ManuallyDrop<T> works on nightly/beta, but not on stable. I can't seem to find the PR/issue tracking this, does anyone have a link? Do anyone know if this will this land for 1.21?

this is the test I'm referring to.

[ldr709]

@kjetilkjeka Here is the PR. Rust 1.21 has already been released and it doesn't have it. According to this if it is in beta now it should be in 1.22 (maybe a few weeks?), but I don't know much about it.