Drop is deterministically invoked at the end of the innermost scope (unless the value to be dropped is moved from or
std::forgetten), therefore one does know when it’s doing its magic even if it’s implicit.
There is another (perhaps more important) reason:
Drop is associated with “teardown”, ie. that is exactly the time we stop caring about a value. When we stop caring about a value, it’s way less important what is happening to it than it was before.
Drop does have the problem of invoking arbitrary code. It is possible to perform sneaky or even malicious things in a drop impl, nothing actually prevents you from doing so as far as I know.
However, and this is my third point, the benefits of the existence of an automatic cleanup mechanism enormously outweigh this disadvantage, so we can live with it: it’s a net win. The same is not true about implicit cloning. The only advantage of implicit cloning would be slight writing convenience, and that is not nearly enough to justify the loss of control it would result in.
I do understand your proposal, please don’t reiterate it for the third time. I do know that not every clonable type would be implicitly cloned under this proposal. However, I am still arguing that the current implicit copying capabilities of Rust are sufficient and correct, and that no type that is non-
Copy should be cloned implicitly.