> In other words, `mem::forget` can only be defined in terms of Drop (or default drop behavior for a type) in terms of ownership semantics, because its signatur

> In other words, `mem::forget` can only be defined in terms of Drop (or default drop behavior for a type) in terms of ownership semantics, because its signature admits no other possibilities. But again, Drop is a destructor trait. It might be confusing that this shares a name with the concept of "dropping" in Rust, which is when a value goes out of scope, but they're not the same thing. Not every value has Drop, and mem::drop doesn't just work for values that are Drop. It is not defined in terms of Drop, but just Rust's ownership semantics. In fact, you can define a `drop` function that only accepts Drop types: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d04ba37c7e7abdad43b70defd8d3c5e5 https://play.rust-lang.org/?version=stable&mode=debug&editio... Although I am disappointed that the automatically generated Drop glue doesn't "count" for this purpose, and there isn't a higher level Drop trait, so this isn't a fully general solution. I also don't know where the concept of "undroppable" came from for this conversation. Taken literally, that would mean that the compiler would emit an error any time a value of that type would need to be dropped, so those values could only exist in functions that either return them or return `!`, or as global static values. I never suggested that was a possibility, and Rust does not support types that are undroppable, but it does support types that are not Drop.