#[may_dangle], a refined dropck escape hatch (tracking issue for RFC 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.

Rollup merge of rust-lang#34764 - pnkfelix:attrs-on-generic-formals, r=

Rollup merge of rust-lang#34764 - pnkfelix:attrs-on-generic-formals, …

see also #28498

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:

Replace uses of `#[unsafe_destructor_blind_to_params]` with `#[may_da…

Rollup merge of rust-lang#38664 - apasel422:may-dangle, r=pnkfelix

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)

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.

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.

Rollup merge of rust-lang#129235 - GoldsteinE:check-may-dangle, r=com…

Unrolled build for rust-lang#129235

@camsteffen

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.

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:

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.

I would like unsafe(may_dangle) so it could be used with cfg_attr! to avoid duplicating drop impls for crates with a nightly feature.

Navigation Menu

Repository navigation

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

42 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

pnkfelix commented on Oct 10, 2016

pnkfelix commented on Oct 26, 2016

42 remaining items

camsteffen commented on Aug 8, 2022

Manishearth commented on Sep 23, 2022

Manishearth commented on Sep 23, 2022

GoldsteinE commented on Aug 20, 2024

GoldsteinE commented on Sep 1, 2024

RalfJung commented on Sep 1, 2024

Zoxc commented on May 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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