Repository navigation
if let should pre-drop wrt else #103108
Description
Consider this snippet:
struct Foo<'a>(&'a mut u32);
impl<'a> Drop for Foo<'a> {
fn drop(&mut self) {
*self.0 = 0;
}
}
fn main() {
let mut foo = 0;
if let Foo(0) = Foo(&mut foo) { // Doesn't compile
} else {
*&mut foo = 1;
}
if matches!(Foo(&mut foo), Foo(0)) { // Compiles
} else {
*&mut foo = 1;
}
}Here, if let complains about an access of foo in the else branch, while if is okay with this.
This is due to if let dropping its temporaries after the else block. This is not neccessary, it could also drop them before.
Similar to #103107
cc @Nilstrieb
@rustbot label T-lang
Reacted by Lily and Toshit Chawda
Activity
Noratrieb commentedon Oct 16, 2022
This is probably a leftover from the time when
if letused to desugar to amatch, which keeps the scrutinee temporaries alive until the end of the match.Dropping them early would be more consistent with if (it cannot be quite consistent as if let needs to keep them alive during the if block) but less consistent with match. Since if let is closer to if than match, I agree that it should behave more like it.
But I don't think we can change this. It could break code in extremely subtle undetectable cases (think of some kind of lock being held in the condition which is then required in the else branch). This also makes it hardly editionable, from a migration and also from a future rustc maintenance perspective.
est31 commentedon Oct 17, 2022
Good point about the consistency. There are analogous drop order optimization for matches too: You can drop the scrutinee temporaries before entering the body of any arm that is binding free and only followed by other binding-free arms, so cases like:
for example, you would drop the temporaries before entering the bodies of the
ValBand_arms. Applied toif let, this would mean always dropping beforeelse, and iff the pattern is binding free, also dropping before the then body.But even without that extension, I'd be okay with the inconsistency with
matchif it makes more programs compile and drops resources more early on.You are right, code might depend on the current behaviour and it might cause slight bugs. OTOH, one could also argue that if you rely on that specific quirk of drop order, then maybe your program was buggy from the start.
<insert spacebar heating xkcd>:).Auto merge of rust-lang#107251 - dingxiangfei2009:let-chain-rescope, …
Auto merge of rust-lang#107251 - dingxiangfei2009:let-chain-rescope, …
est31 commentedon Nov 7, 2024
The given example compiles now on edition 2024, I suppose since #131984?
Also, #131154 contains a lot of useful discussion about this question.