#[may_dangle], a refined dropck escape hatch (tracking issue for RFC 1327)

[pnkfelix]

Tracking issue for rust-lang/rfcs#1327

• Allow attributes on lifetime/type formal parameters (generic_param_attrs feature): Attributes on generic formals #34764
• Add #[may_dangle] attribute for lifetime/type formal parameters on unsafe impl<...> Drop (dropck_eyepatch feature)
• Replace uses of #[unsafe_destructor_blind_to_params] attribute in libstd with #[may_dangle] Replace uses of #[unsafe_destructor_blind_to_params] with #[may_dangle] #38664
• Update nomicon to use #[may_dangle] instead of #[unsafe_destructor_blind_to_params] Update nomicon to describe #[may_dangle] #39196
• Remove support for #[unsafe_destructor_blind_to_params] attribute (with warning cycle before removal).
  • Deprecated in Deprecate #[unsafe_destructor_blind_to_params] #38970
  • need to replace remaining references (e.g. in test suite) to #[unsafe_destructor_blind_to_params] with [may_dangle] before we can actually remove the former.

For docs explaining the feature, also see the forge.

[pnkfelix]

see also #28498

[pnkfelix]

Some people (myself included) have noted that may_dangle is not an ideal name. (Some have gone so far as to call it "terrible".)

Perhaps we could return to calling it an eyepatch:

[RalfJung]

I have to say I find may_dangle clearer than eyepatch. After all the idea (if I understood it correctly) is that for the given parameters, it may be the case that they do not necessarily outlive the current function call.

[asajeffrey]

An issue that came up in the context of Josephine is asajeffrey/josephine#52. This is mainly an issue for the interaction between the drop checker and untagged unions (#32836 (comment)) but does have impact on the code guidelines for when may_dangle may be used safely.

The issue is the text "When used on a type, e.g. #[may_dangle] T, the programmer is asserting the only uses of values of that type will be to move or drop them," and whether the programmer is allowed to discard values of type T, that is reclaim the memory used by the value without running T's drop code. In particular, is the programmer allowed to safely mem::forget a value of type T?

[SimonSapin]

std::mem::forget itself is not unsafe. I believe that leaking any value (never running destructors) is considered sound in Rust. (This is why for example scoped threads are based on closures rather than "guard" values with destructors.)

[tesuji]

#62568 will remove support for #[unsafe_destructor_blind_to_params] attribute.

[qnighy]

Is there anything I can help to stabilize this feature?

[pnkfelix]

I don't think we intend to stabilize #[may_dangle] as is. It is a stop-gap measure until we can develop a more disciplined solution to the problem (e.g., some kind of where-clause on the type, perhaps coupled with an effect-system to allow us to actually check that one is adhering to the may-dangle rules).

[vincent-163]

Hello. I'm proposing out-of-lifetime references which may be a potential solution to this problem: https://internals.rust-lang.org/t/proposal-about-out-of-lifetime-references/11675/11. Please take a look and leave any feedback or suggestions!

[KodrAus]

We have some new docs in the forge on #[may_dangle] that folks trying to understand it may find helpful. It includes a real example of where we (by we I mean me) got it wrong the first time.

[m-ou-se]

I don't think we intend to stabilize #[may_dangle] as is. It is a stop-gap measure until we can develop a more disciplined solution to the problem (e.g., some kind of where-clause on the type, perhaps coupled with an effect-system to allow us to actually check that one is adhering to the may-dangle rules).

It's been a few years, and it doesn't seem like there will be a proper solution for this problem any time soon. Maybe it's time to stabilze #[may_dangle], to allow crates other than core/alloc/std to use it?

[camsteffen]

Trivial blocker. There doesn't seem to be any restriction on where #[may_dangle] is allowed. It is currently allowed on const params, types, statements, etc. and shouldn't be AFAICT. (playground)

[Manishearth]

perhaps coupled with an effect-system to allow us to actually check that one is adhering to the may-dangle rules

I feel like for an unsafe escape hatch it's probably not a great idea to have a strong effect system situation? If you're using this you're already doing some unsafe tricky thing; the user is already in a situation where they can't prove safety to the compiler; asking them to prove safety seems suboptimal

I also do agree that this should be stable; being able to implement a stable Vec<T> seems like something that rust should let you do, and there's no easy workaround to this at the moment.

[Manishearth]

A workaround hack that can sometimes work is taking types of the form:

pub struct MyAbstraction<'a, T> {
   stuff: *const T,
   more_stuff: bool,
   even_more_stuff: usize,
   marker: PhantomData<&'a T>,
}

and turning them into this:

pub struct MyAbstraction<'a, T> {
   eyepatch: MyAbstractionEyepatchHack< T>,
      marker: PhantomData<&'a T>,
}
struct MyAbstractionEyepatchHack<T> {
   stuff: *const T,
   more_stuff: bool,
   even_more_stuff: usize,
}

and implementing Drop on the inner type. It's more of a problem if the lifetime is really needed in your internal stuff, though.

[GoldsteinE]

It is a stop-gap measure until we can develop a more disciplined solution to the problem (e.g., some kind of where-clause on the type, perhaps coupled with an effect-system to allow us to actually check that one is adhering to the may-dangle rules).

Nearly five years have passed since this comment. As far as I’m aware, there’ve been no proposed solution and no goal to make one. I think it’s safe to say by this point that unless some actions are deliberately taken, the status quo will remain indefinitely.

I think this state of affairs is less than satisfactory. As of now, it’s impossible to properly implement collections outside of the standard library. This interacts poorly with std’s (completely reasonable) desire to remain lean and leave more complex features to the ecosystem. For example, #56167 was recently closed because one can just use hashbrown, but hashbrown can’t provide a proper dropck interaction on stable. You need to choose between accurate dropck and advanced collection features.

I don’t think blocking this on figuring out effect system, a massive feature that’s not really planned, is reasonable. A different syntax (e.g. where clause instead of an attribute) doesn’t need to block stabilization of this one — a lot of features changed syntax over time, e.g. try!() or recently addr_of!(), and it’s usually not a big deal.

I think it’s time to at least reevaluate the decision to leave this perma-unstable (even if it results in “yes, we’re leaving this perma-unstable because {reasons}” from T-lang). For what it’s worth, I fixed the technical blocker highlighted by @camsteffen.

[GoldsteinE]

I chatted in Zulip for a bit, so here’s the status of this as I understood it.

The current version of #[may_dangle] will not be stabilized as it’s too error-prone. There’re some proposals for a different semantics, most notably rust-lang/rfcs#3417, but they’re kinda stalled. lcnr, who is the author of that one, said:

I would be happy if someone were to look into that RFC to push it's core idea over the finish line though and would then be fine with stabilizing it. That's a lang team question though

I’m not totally sure, but as far as I understand it means it’s blocked on t-lang.

Here’re the Zulip threads:

• https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Perma-unstable.20status.20of.20.60.23.5Bmay_dangle.5D.60/near/465417610
• https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/Perma-unstable.20status.20of.20.60.23.5Bmay_dangle.5D.60

[RalfJung]

It's not fully blocked on t-lang -- it needs someone who's taking over that PR to suggest and explain the idea to t-lang.

However, before doing that it'd probably be good to ask for a t-lang liaison to ensure the team has the bandwidth to consider the proposal.