Description
Proposal
The main goal of this proposal is to redefine dropck in terms of bound-like constructs. We believe this to be a good first step towards deprecating may_dangle (and hopefully generally avoiding issues like rust-lang/rust#99413 entirely) and possibly stabilizing something similar in the future, tho our main goal is to see if it's even possible in the first place.
We believe it is sufficient to have 3 kinds of dropck-related bounds: "drop" bounds, "borrow" bounds, with these being inferred by default for non-Drop types, and "access" bounds, the default for Drop types. A "drop" bound indicates values of the given type may be dropped, and a "borrow" bound indicates values of the given type are borrowed and will not be dropped.
To match existing rules, Copy types are generally composed exclusively of "borrow" bounds: this includes shared references and pointers. The exception to this is PhantomData, which has a "drop" bound instead. (N.B. This is overly restrictive, but matches existing rules, and is observable on stable. It might be worth reconsidering/changing this after a crater run and removal of may_dangle however.) On the other hand, the 2 special non-Copy types are mutable references and ManuallyDrop, both of which have a "borrow" bound. Everything else follows inference from these and Drop impls, which by default have only "access" bounds (the existing may_dangle mechanism should be deprecated, but before being removed and replaced with "something better", it can simply be redefined to not apply "access" bounds to the relevant parameter, and do the inference stuff as described here; we can figure out "something better" another time).
The inference rules for these dropck bounds are pretty simple: there's a hierarchy of dropck bounds ("access" is stronger than "drop" is stronger than "borrow"), and when a generic type contains generic fields, it gains the weakest possible bound that satisfies these. For example:
struct Foo<T> {
drop_bound: PhantomData<T>,
borrow_bound: *const T,
}causes T to have a "drop" bound, because that's the weakest bound satisfying both PhantomData<T> and *const T, meanwhile:
struct Foo<T> {
borrow_bound: *const T,
}only gives T a "borrow" bound, and finally:
struct Foo<T: Display> {
access_bound: PrintOnDrop<T>,
}
struct PrintOnDrop<T: Display>(T);
impl<T: Display> Drop for PrintOnDrop<T> {
fn drop(&mut self) {
println!("{}", self.0);
}
}gives T an "access" bound.
We believe these are sufficient to capture all necessary dropck semantics and provide a pathway for removal of may_dangle. This MCP does not propose any interactions between these bounds and function code at this point, in other words, it doesn't apply any restrictions to Drop impls or to drop_in_place, tho that would certainly be an obvious next step. The main question is whether or not this actually does capture all the necessary dropck semantics and whether it can be built upon or should be scrapped.
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.