Dropck doesn't have to exist, and it would make learning the language easier

[Soni]

dropck is complicated and confusing, many folks we've talked to say they can't understand dropck at all. at the very least we'd like them to be able to understand dropping a little better than they do today, and if we can't get them to understand dropck... what if we didn't need to have dropck at all? then they no longer need to understand dropck in order to understand dropping! and we think we can get rid of dropck entirely.

we could have it so "dropck" is, conceptually, simply a syntactically hidden function call. like so:

{
let x = something();
x.something_else();
x.do_thing();
}

is exactly as

{
let x = something();
x.something_else();
x.do_thing();
unsafe { Drop::drop(&mut x); }
}

(at least, when panic=abort... unwinding makes this a bit more involved) and we can do this if we figure out how to represent the relevant dropck semantics as part of normal function calls.

specifically, breaking(ish) dropck semantics out of drop allows ppl to understand them as separate concepts. this makes it easier to understand them: you learn the semantics, then you learn drop (or vice-versa), then you combine the two. instead of having to learn them as part of learning drop.

(posting this as a new thread instead of part of Towards may_dangle stabilization* because we couldn't really make this fit with the tone of that post... sorry)

[steffahn]

I feel like in light of the fact that drop check considers things like whether or not Drop implementations exist, and whether they have #[may_dangle] attributes, it’s hard to imagine how this would generalize to something useful for other normal function calls.

---

On a different note, one thing I’d like to point out to avoid anyone teaching anyone the wrong thing: the naive

unsafe { Drop::drop(&mut x); }

translation of dropping is not only incorrect in not capturing nuances of dropck, but also on a more fundamental level, on two accounts

• the general case of dropping variables in Rust involves drop flags (often “optimized” into static analysis) to make sure that moved-out-of or uninitialized variables (or fields) are not dropped
• the drop glue of a something like a POD (e.g. Copy) type is actually calling nothing, since a Drop::drop method was never defined), and on the other hand, the drop glue of types in general does not only call Drop::drop for the type itself (if it exists), but also recursively executes the drop glue for all of its fields, which is a separate (subsequent) operation, not part of the implementation of Drop::drop itself

[Soni]

yes, we are overlooking drop elaboration but drop elaboration isn't dropck. it's a separate step in the drop mechanism.

and honestly? we already have (an equivalent of) may_dangle within function scope. (yes it's called drop flags. sorta.)

let mut x;
{
  let y = 1;
  x = &y;
  println!("{}", x);
}
{
  let z = 2;
  x = &z;
  println!("{}", x);
}

it's just a matter of extending it across function scopes.

(more interestingly is what happens when you have a bigger, but non-Drop, type. since each field is considered independently.)