Stabilize may_dangle using borrowck

[SoniEx2]

Rendered

---

This is more or less as it says, the goal is to stabilize may_dangle, sorta.

This RFC effectively turns dropck problems into borrowck problems. There are many analogs of dropck problems in the borrowck world, including but not limited to lifetime specialization. We think this is pretty neat. This is also roughly similar to the "Parametricity via some ?-Bound" approach discussed in the original UGEH RFC: https://rust-lang.github.io/rfcs/1238-nonparametric-dropck.html#parametricity-via-some--bound , tho we wouldn't call this RFC actually parametric (tho we're not entirely sure what "parametric" means tbh).

Previous PR: #3331
Current Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/deprecating.20spooky-dropck-at-a-distance

Also, acknowledgements: Thanks to the folks who encouraged us to make this a thing. It was kind of an accident (we were trying to explain the idea to folks, and then it kinda... happened). We hope this is okay.

[vi]

Will it somehow interact with "move references" (unique references that drop, but not deallocate a value) or moveit?

[SoniEx2]

@vi yes. hopefully without being a problem, tho.

[Diggsey]

pub unsafe fn drop_in_place<T: '! + SafeToDrop + ?Sized>(to_drop: *mut T) {...}

For this change to be backwards compatible, the compiler needs to be able to infer that any normal T (ie. a T with the implied bounds) implements SafeToDrop, which it won't be able to do if SafeToDrop implementations are generated exactly as specified in the RFC. You'd need to make SafeToDrop an implied bound of every generic (relaxed by : '!).

I also wonder whether it's appropriate to use '! for this syntax. AIUI, this is syntax that will be rarely used outside of the standard library, and for such rarely used features it's better to use a keyword rather than a symbol. (Since it's more descriptive and more easily searchable). An existing keyword lifetime could be used instead (eg. 'priv) or else a new lifetime keyword could be reserved in the next edition.

[SoniEx2]

eh, with selfref, this could get used a lot. we like the '! syntax because it prevents someone from proposing '! to mean the empty lifetime, which is unsound and thus is never gonna happen. but this can be bikeshedded ad nauseam.

and as far as we can tell the SafeToDrop as generated always satisfies T: SafeToDrop when T: 'fn, even when extra bounds are around (like U: Display or whatnot). tho the compiler might have to assume that (or, indeed, imply that) since it isn't necessarily aware of the rules around SafeToDrop impls. we'd love to see an example where it breaks?

[Diggsey]

as far as we can tell the SafeToDrop as generated always satisfies T: SafeToDrop when T: 'fn, even when extra bounds are around (like U: Display or whatnot)

Right the concrete type does always satisfy it, but in a generic context the compiler can't use reasoning like that, because it can't exhaustively test every type, it has to prove one set of bounds (T: SafeToDrop) from another (T: 'fn).

[SoniEx2]

nod tho we'd rather not have to add multiple new ?-style bounds. these seem tightly coupled enough that it makes sense to tie them together in a relatively straightforward way.

[lcnr]

had this RFC, or well rust-lang/types-team#85, in my notifications for a while and am finally taking some time to look at this.

While I can't speak for the rest of t-types my current vibe is:

• the existing dropck rules are incredibly complex and afaik not well explained anywhere, which you show in the "Spooky-dropck-at-a-distance"
• encountering the need for #[may_dangle] is a very rare issue and nearly no users are aware of it
• '! is not searchable and imo 'too weird' to be in the std source. THis should be an attribute, even if that attribute were to have the same behavior as '!. It's easier to search for attributes and #[may_not_be_alive] or well, #[may_dangle] at least give the user some direction on what this may mean.
• the changes to implied bounds feel dangerous and fairly complex to reason about. &'a &'b () implying 'b: 'a is a quite fundamental rule rn.
• the types team currently does not have the capacity for this change. This may change in the future once we have a better formalization of the existing rules, but that feels like it would still be quite far off.

while I haven't been involved in the recent discussions about dropck rules I am very happy that someone is actually trying to untangle that mess ❤️

I think this RFC should be either postponed or closed. Even if we have the necessary capacity in the future, I don't feel like this is worth the added complexity. In my experience #[may_dangle] is very isolated to dropck and does not affect a lot of other code. This would change with this proposal as '! would impact far areas of the compiler/language.

[SoniEx2]

we hear that. at the same time, the main motivation for trying to push this forward isn't what it'd bring to selfref or to third-party collection types, but what it'd bring to rustc and std developers. particularly the removal of an (in our opinion) fairly significant footgun, as well as peace of mind about no longer having to worry about spooky-dropck-at-a-distance.

rustc/std developers have shot themselves in the foot with may_dangle before. we don't feel like the existing safeguards (which mostly amount to code review) are enough to keep it from happening again. further, stabilization (and specification) prevents it from changing again in the future, and such a core part of the language's safety guarantees should not be subject to silently change as it is today.