I’m not sure how much sense it makes to keep arguing this point, since I doubt it’s going to change any minds, and in any event it seems like the project has made a decision that likely won’t be re-litigated (or at least not before a significant time passes), but I use the word “drop” in the sense of “variable’s resources can be reclaimed”, which is (I think) the same formulation adopted by the eager drop RFC. That is, for non-copy types, a “drop” can be caused by passing the variable to
std::mem::drop, whether or not the variable’s type has a
The relevance here is that I’d consider “drop”, generally, to be the natural converse of RAII, which could be called RRID (or, Resource Release Is Destruction). Viewed this way, a “drop” of a borrow pointer currently has the effect of releasing the borrow. I still think that eager drop on borrow pointers is semantically indistinguishable from the scheme described by the SEME RFC (though that RFC does goes into more detail regarding the eager drop mechanism, and into treatment of temprorary values). In other words, I can’t think of a case that the SEME RFC covers that wouldn’t be automatic if eager drop (using the SEME mechanism for determining the last use of a value, and with the SEME enhancements regarding pattern matching on enums) had been incorporated.
I understand that you and others view borrowing as a separate concern from other types of resource release, which is reasonable considering the importance of borrow semantics in the language. Fixing the borrow checker to allow more borrows does not have nearly the backwards-compatibility risk that a generalized eager drop would, and seems likely to be accepted in the near-ish term. I don’t intend to keep fighting a lost battle, I just hoped to communicate and refine my understanding of the situation.