Repository navigation
Once confident in dropck: remove #[unsafe_destructor] attribute #22196
Description
Activity
Nominating; we should decide whether we are going to do this for 1.0 beta, or if it can wait until the 1.0 release itself as a "polish issue." (or if it can wait even beyond that, i.e. to 1.x. But I am not advocating that position.)
(However, given that #21972 just landed today, it may be a good idea to let the code settle for a week before we actually make a decision about this. Its super easy to remove
#[unsafe_destructor], as one can see from the two commits here, its just a matter of having the will to do it. :) )- changed the title
[-]Once confident in Sound Generic Drop: remove `#[unsafe_destructor]` attribute[/-][+]Once confident in dropck: remove `#[unsafe_destructor]` attribute[/+]on Feb 11, 2015 1.0 beta, P-high.
@pnkfelix, thanks! For what it's worth, I was able to remove the
unsafe_destructorfeature in my library by moving some of the fields of my struct into a new, non-generic struct and implementingDropon that instead of the generic struct: SSheldon/rust-objc@b2bd3e0. (For anyone else that runs into this, that could potentially be a workaround.)If you can't unfeature gate the entire unsafe_destructor, would it be possible to only unfeature gate those Drop impls we're confident with? Like, the simple and obvious ones (for various values of "simple" and "obvious" :-) ). I suspect a majority of Drop impls would be simple and obvious.
at this point I have a patch for the main known issue : PR #23638.
An audit of
libstdstill needs to happen, but I would be okay with doing that in between the beta release and 1.0 (and unfeature-gating#[unsafe_destructor]in the meantime. I'll bring it up with the team.- added a commit that references this issue
on Mar 28, 2015 - added a commit that references this issue
on Mar 29, 2015 - added a commit that references this issue
on May 16, 2015
Spawned off of #8861, this is the last step in RFC #769, Sound Generic Drop.
Basically, once we are relatively confident that:
dropckcode is at least a sound approximation of that rule, andthen we should remove the
#[unsafe_destructor]attribute and all the uses of it.