Closed
Description
Tracking issue for rust-lang/rfcs#1860
I believe initially implemented at #40559
Metadata
Metadata
Assignees
Labels
Blocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCRelevant to the library API team, which will review and decide on the PR/issue.In the final comment period and will be merged soon unless new substantive objections are raised.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
Ericson2314 commentedon Mar 20, 2017
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
&moveand improvedDropagain 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&moveisn't needed).SimonSapin commentedon May 19, 2017
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 commentedon May 24, 2017
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 commentedon May 31, 2017
I don't believe
&moveor a newDropare anywhere near the horizon. It seems unreasonable to hold this API up indefinitely.@rfcbot fcp merge
rfcbot commentedon May 31, 2017
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams:
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 commentedon Jun 7, 2017
I filed rust-lang/api-guidelines#93 to follow up with a justification of why we prefer
into_inner(ManuallyDrop<T>)overinto_inner(self).@rfcbot reviewed
Ericson2314 commentedon Jun 7, 2017
Fair enough, this can always be deprecated.
SimonSapin commentedon Jul 3, 2017
@brson I think this is waiting on you :)
rfcbot commentedon Jul 8, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
3 remaining items
bluss commentedon Aug 5, 2017
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 commentedon Aug 6, 2017
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&i32to represent the discriminant ofOptionbecause the&i32items might be uninitialized.Or, in other words,
ArrayVecneeds some way to inhibit propagation of enum layout optimizations, andManuallyDropcould be it.std: Stabilize `manually_drop` feature
ldr709 commentedon Aug 27, 2017
This is probably neither the right time nor place for this, but any plans to
impl Copy? It may seem odd to do so, sinceCopytypes can be dropped trivially, but this would be useful in situations where you don't know whether or not a typeimpls Copy.Gankra commentedon Aug 28, 2017
You can submit a PR to derive(Copy) and it will likely be accepted.
kjetilkjeka commentedon Nov 9, 2017
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 commentedon Nov 16, 2017
@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.