MaybeDangling

[RalfJung]

Declare that references and Box inside a new MaybeDangling type do not need to satisfy any memory-dependent validity properties (such as dereferenceable and noalias).

Rendered

Thanks to @rust-lang/wg-unsafe-code-guidelines for a lot of helpful feedback :)

Tracking:

• Tracking Issue for MaybeDangling rust#118166

[CAD97]

Does MaybeDangling have any impact on lifetimes? I assume not, but it's unfortunately close to #[may_dangle] (the dropck eyepatch) which does.

Some naming alternatives

Only slightly tongue-in-cheek:

• Dormant, Inactive, Suspended, etc — the point is to turn off enforcement of the type's "special" memory related properties. Validity is still required, but I think this communicates the intent of only enforcing the "special" properties lazily when used.

  These names might much more strongly want access to the wrapped type to be explicit (but still safe) rather than through Deref, though, as they're much more "active" in what they're saying.

• Launder — like C++'s std::launder, it's about hiding properties from the compiler, and like std::launder, it's a very necessary tool that nonetheless is only needed in a small set of low level building blocks.

These names also have the advantage of not implying they only impact dangling/dereferenceable but not uniqueness/noalias.

---

I also find it somewhat amusing that this kind of ends up introducing a new pointer type. MaybeDangling<&'a [mut] T> offers some interesting opportunities to replace some NonNull<T> usage.

[RalfJung]

Does MaybeDangling have any impact on lifetimes? I assume not, but it's unfortunately close to #[may_dangle] (the dropck eyepatch) which does.

Oh... yeah that is not great. :/

I also find it somewhat amusing that this kind of ends up introducing a new pointer type. MaybeDangling<&'a [mut] T> offers some interesting opportunities to replace some NonNull usage.

This is still quite different from NonNull. MaybeDangling<&mut T> is not Copy and each time you use it, that will create a mutable reference (via the DerefMut implementation) which comes with all its usual aliasing gurantees!

NonNull is suited for actually aliasing data. MaybeDangling<&mut T> is suited for cases where the reference is "on hold" and aliases exist but the reference will only be used again once the aliases are gone.

Dormant, Inactive, Suspended, etc — the point is to turn off enforcement of the type's "special" memory related properties. Validity is still required, but I think this communicates the intent of only enforcing the "special" properties lazily when used.

I like those, they match the previous sentence about being "on hold".

These names might much more strongly want access to the wrapped type to be explicit (but still safe) rather than through Deref, though, as they're much more "active" in what they're saying.

Hm... yes maybe? No strong opinion here; I assumed it'd be Deref because ManuallyDrop is.

[Pointerbender]

These names might much more strongly want access to the wrapped type to be explicit (but still safe) rather than through Deref, though, as they're much more "active" in what they're saying.

Hm... yes maybe? No strong opinion here; I assumed it'd be Deref because ManuallyDrop is.

This is a good observation, because the documentation of Deref says the following:

Implementing Deref for smart pointers makes accessing the data behind them convenient, which is why they implement Deref. On the other hand, the rules regarding Deref and DerefMut were designed specifically to accommodate smart pointers. Because of this, Deref should only be implemented for smart pointers to avoid confusion.

Note that ManuallyDrop is not always wrapped around a smart pointer! Looking back at its RFC this was not brought up then. MaybeDangling<..> does have a use case for wrapping Box<T> and &mut T, so here it less in conflict with the documentation of Deref, but still it could wrap a non-pointer type (this is not of any practical use, though).

Should MaybeDangling implement Deref and DerefMut like ManuallyDrop does, or should accessing the inner data be more explicit since that is when the aliasing and validity requirements do come back in full force?

As mentioned in the RFC, the difference between ManuallyDrop and MaybeDangling is that the latter is intended for maybe-aliasing capabilities, in addition to both supporting maybe-dangling properties. This maybe-aliasing property being a potential mild footgun for safe Rust code implicitly dereferencing an aliasing MaybeDangling, combined with the documentation of Deref, seem to suggest that MaybeDangling might be better off not implementing Deref and expose explicit methods for that instead. Or as an alternative, it could only implement Deref<Target=T::Target> when T also implements Deref to stay as close to the documentation of Deref as possible, but this could also hurt composability of MaybeDangling<T> and does not remove the footgun, so that is not ideal either. Finally, whether MaybeDangling implements Deref or not would also have consequences for whether its methods could be implemented as regular methods or as associated functions, so there is a UX aspect to this, as well.

I also don't have a strong opinion here, but it seemed worthwhile to at least consider this for the decision for whether to implement Deref or not :)

[comex]

MaybeDangling<&mut T> is not Copy

To clarify, is MaybeDangling<T> Copy if T is?

[RalfJung]

To clarify, is MaybeDangling Copy if T is?

Yes, it propagates all the auto traits and Copy. It should probably derive(Copy, Clone, Debug) and maybe more.

[CAD97]

(@Pointerbender FWIW the "for smart pointers" wording has been considered for removal a few times before, and still is. The general consensus is more along the lines of "when &Self should be implicitly usable as &Target" plus guidelines around avoiding method conflicts. In addition to ManuallyDrop, std also has the unstable LazyLock/LazyCell which aren't pointers persay but do implement Deref.)

[RalfJung]

A potential future possibility with this RFC is to use it to resolve the self-referential-generator-aliasing situation: these generators need to be pinned anyway, and if we define Pin<T> as a newtype around Pin<MaybeDangling<T>>, then Pin<&mut T> no longer makes any aliasing assumptions so we wouldn't need anything else (such as the current special treatment of Unpin) to make self-referential generators sound.

[CAD97]

That's not fully sufficient by itself; you still need some way to do pin projection. Currently that's done with the _unchecked methods which require using the actual &mut.

[RalfJung]

Hm... yeah you are right, those &mut are short-lived but they do add intermediate noalias assumptions.

[Pointerbender]

Do the effects of MaybeDangling also recurse into the pointee and/or pointee's fields? E.g. will MaybeDangling<Box<Box<&mut T>>> also strip the &mut T from its memory-dependent validity obligations, or would that require a MaybeDangling<Box<Box<MaybeDangling<&mut T>>>> to that effect?

[RalfJung]

A Box<Box<&mut T>> doesn't have aliasing requirements on the inner pointers to begin with, so there's nothing there for MaybeDangling to strip.

[kornelski]

Perhaps making ManuallyDrop more magical would suffice?

It makes sense to me that an object with dangling references is dropped manually, because user of that type already has to be careful about when it is dangling (e.g. drop order of fields in self-referential structs is important).

In the worst case it should be possible to make a DIY MaybeDangling with AutomaticallyDrop<T>(ManuallyDrop<T>) with a Drop.

[RalfJung]

The alternative is mentioned in the RFC. The RFC also has 2 use-cases for MaybeDangling that want automatic drop, so it seems better to have ManuallyDrop use a MaybeDangling type rather than awkwardly implementing a dropping MaybeDangling on top of ManuallyDrop.

[tmandry]

Separately, I think we should also just move forward with this RFC, given the argument made in the RFC (and by @scottmcm in the aforementioned lang team meeting) that we will need a wrapper type for this even if we also have an attribute for it.

@rfcbot reviewed

[RalfJung]

I have created an issue to track the experiment: rust-lang/rust#118166. Looking for someone to implement the type and its magic behavior now. :)

[danielhenrymantilla]

Btw, the RFC could nowadays mention https://docs.rs/maybe-dangling as a third-party implementation thereof

[Jules-Bertholet]

Extreme pedantry: arguably, "prior" in "prior art" as used by the RFC template means "prior to when this RFC is accepted." The history of past revisions of the RFC document is not part of the final product that gets FCPed and published in the RFC Book. So "prior art" is an accurate description of https://docs.rs/maybe-dangling, and the RFC template is perfectly innocent here.

[RalfJung]

That's not how the term "prior art" is usually used in scientific context. When there is a causal dependency where A caused B, then B cannot be prior art of A, even if the publication of paper A happens after B becomes public. (There is often a significant delay between writing and submitting a paper, and having it published.) Here, as far as I can see, the RFC inspired that crate, so if anything the RFC is prior art for the crate, not vice versa.

Alas, I have several gripes with the strict form of the template, but not the patience to try and fix it.^^

[Jules-Bertholet]

The way I see it, the initial draft of the RFC inspired the crate, which in turn inspired a subsequent draft. But that subsequent draft should be considered a distinct document from the initial draft. Published RFCs, unlike scientific papers, are considered as emanating from the team that approved them, and represent the perspective of that team at the time of FCP approval (the original author is not even listed in the RFC Book).

[RalfJung]

I disagree, but it doesn't seem useful to discuss this here.

[oxalica]

How is it possible to have both (1) MaybeDangling<P> and P are safely convertible and (2) P holds more guarantees than MaybeDangling<P>? If they are convertible, one could safely pass say MaybeDangling<&'a mut T> to a fn(&'a mut T, ...) which itself is compiled with noalias assumption, and result in undefined behaviors. If P -> MaybeDangling<P> is safe and MaybeDangling<P> -> P is unsafe, then what's the difference between MaybeDangling and MaybeUninit?

I also disagree with the disagreement by @RalfJung 's #3336 (comment):

MaybeDangling as currently specified by the RFC does not change safety invariants, as it implements safe >> Deref conversion like ManuallyDrop does. I argue that this is likely undesirable, and MaybeDangling should instead make it unsafe to reactivate the wrapped type and its invariants.

I think that would make MaybeDangling mostly useless -- one can already use MaybeUninit for something like that. I consider not having to use unsafe code to get the inner data back out of the no-dangling wrapper to be a feature. For example, this would have avoided adding unsafe code in rust-lang/rust#102589.

No. It's intrinsically unsafe to have fn(SomeType<'some_life>) where 'some_life may ends in the middle of the function invocation depending on its logic. In that case (example 2 of this RFC), the validity is controlled by the runtime logic and is impossible to check at compile time (eg. cannot prevent you from "accidentally" swapping closure(); and control.signal_done();), thus guarantees should be made by programmer, unsafe is required, with or without MaybeDangling. Then I don't really see the advantage of introducing another MaybeDangling than MaybeUninit.

The dereferenceability of ManuallyDrop in example 1, I think, is a separate issue. It's a choice between UB on state observed and UB on state exists.

[RalfJung]

How is it possible to have both (1) MaybeDangling<P> and P are safely convertible and (2) P holds more guarantees than MaybeDangling<P>?

There are validity invariants and safety invariants. The safety invariant of P and MaybeDangling<P> are identical, but the validity invariants are not.

Then I don't really see the advantage of introducing another MaybeDangling than MaybeUninit.

MaybeUninit is a terrible solution for example 2 since one has to call drop manually. That's fragile and error-prone. I think it is important that we have a way to not lose automatic drop but still pass around "opaque arbitrary data" without making extra claims about its memory validity.

Once we have implicit drop, there's no reason to make into_inner unsafe, since drop will already implicitly convert to the inner type without unsafe code.

[RalfJung]

Around half a year ago, this was proposed to be merged so we can do experimentation. @joshtriplett @nikomatsakis @pnkfelix any chance you could tick your box? :)

[nikomatsakis]

@rfcbot reviewed

Thanks for the ping, @RalfJung.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[riking]

MaybeDangling<&!> is still invalid

Based on my current understanding of ref-to-never, this can change to "MaybeDangling<&!> has an always-violated safety invariant"

[RalfJung]

&! has an impossible validity invariant according to the Reference, Miri, and MiniRust. So I don't think the text should change.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[traviscross]

The lang team has accepted this RFC and we've now merged it.

Thanks to @RalfJung for pushing forward this important work, and thanks to all those who reviewed this and offered helpful feedback.

For further updates, follow the tracking issue:

• Tracking Issue for MaybeDangling rust#118166

[kennytm]

how about also fixing the template which currently still reads "Rust Issue:" here