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/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. 🔔