This forum has had a long history of topics covering the annoyance. (latest)
A change of behaviour will never be made to the pure code as it would be a major breaking change.
The current "fix" techniques can be hacky.
What if there were a new keyword used in a similar way as .await that rids prior temporaries so they don't linger until the end.
Would you welcome having such addition?
One could be made over an edition (whether it should or not is another question).
My initial reaction is negative. I don't think it would be inherently any more clear. Possibly I could be swayed.
You could also define a method on a mutex that took a closure, obtained a lock, ran the closure, and then dropped the lock. E.g. in the linked thread, you could use something like mutex.run(|x| x.pop_front()).
I think a new keyword would be confusing. What if you wanted to drop some, but not all, temporaries? What if you refactor code into that situation?
For the status quo, the most concise approach I'd know is a macro
macro_rules! drop_tmps {
($e:expr) => {{ let x = $e; x }}
}
Wisdom borrowed from JS, the IIFE can solve many existing problems in Rust.
let c = RefCell::new(vec![42]);
// panic
if let Some(n) = c.borrow_mut().pop() {
c.borrow_mut().push(n);
}
// fine
if let Some(n) = (|| c.borrow_mut().pop())() {
c.borrow_mut().push(n);
}
I guess that's an overstatement. I don't remember ever hitting this problem during my 7 years with Rust (and if I did, it was not annoying enough to be worth remembering).
People like to write all sort of weird code and expect the compiler to be smart enough to figure everything out. Don't write weird code and you'll live a long, happy life, without having to force language changes onto everyone.
No. Rust definitely doesn't need more syntax sugar or minor "features" like this. We've got too many of them already.