I would like to make the case that Rust is missing a fundamental capability that C++ has which is a very powerful and simple means to avoid logic errors. That is the concept of 'janitorial RAII'. Unlike 'normal' RAII, which Rust has obviously, where an object cleans itself up on Drop, janitors are designed to apply some change to a member of 'self' on a scoped basis, possibly in a nested fashion.
So something like:
struct Foo
{
exploder_mode : bool;
}
impl Foo
{
pub fn SomeCall()
{
// some stuff
{
// Enter exploder mode for this scope
let exploder_jan : BoolJan = BoolJan::new(&mut exploder_mode, true);
// Exploder mode gets put back to original value here
}
}
}
A trivial example but it demonstrates the point. This is seemingly fundamentally impossible in Rust as it stands, because such an object requires mutable access and keeps it until it itself is dropped. That leaves the called structure inaccessible and hence useless.
I think that this could be dealt with without too much undue craziness, and it would be such a benefit. Such a type can only do three things. It can have associated functions to create it, it can implement Drop, and it can 'orphan' whatever it's been given (so it does nothing on Drop.)
All that is needed is an indication to the compiler than this object takes a mutable reference but cannot use until it is destroyed. Orphaning doesn't require access to the object being 'sanitized'. The only use of the mutable reference will be in the Drop.
So that would provide a straightforward way to allow this, but to still insure at compile time that the object legally has mutable access, since the compiler knows exactly when it will be dropped. So it would be no different than anything else attempting to get a mutable ref at that point.
There are endless applications for this concept. In my very large C++ code base I use them all over the place to excellent effect. Given that Rust has decided (unwisely IMO) to not support exceptions, anything that requires undoing local changes is a huge burden because it means no more use of ? style convenient error returns, since there's no way to undo these types of scoped changes if that is used. And the manual error propagation of Rust is brutally tedious.
Given that Rust is all about making it hard to do the wrong thing, this simple concept avoids a whole raft of possible logic errors where changes made and intended to be undone are not.
No other scheme I can think of (or anyone else on the Rust Reddit either) would be anywhere near as straightforward to use. You could jump through a bunch of hoops to do it in some way using what's there now, but it would be hacky at best. Keep in mind that it must support nested applications as well, so some of those hacky methods won't even work in that case. A nested scope may create a janitor object for the same method, or a call from method A (which creates one) to method B may create another one and A has no way to know that.
This simple scheme makes all those problems go away in a safe way.
Another simple variation of this that would work via the same principle is the opposite of this, which is the 'Committer' type object, which will store up changes and commit them on Drop, if it has been told to commit, else it does nothing. The two could easily be represented via a pair of trivial traits and use the same mechanisms.
I guess the primary issue is whether there's a means to limit a type implementing these traits to just that very fundamental functionality. Even if it required a new 'lang-item' I think it would be worth it and not one of the particularly complex ones.