Bug in while let and if let?

[bvssvni]

play.rust-lang.org http://is.gd/FWYYn9

use std::rc::Rc;
use std::cell::RefCell;

fn foo(a: &mut u32) -> Option<()> {
    if *a < 10 { *a += 1; Some(()) } else { None }
}

fn main() {
    let a = Rc::new(RefCell::new(4));
    while let Some(()) = foo(&mut *a.borrow_mut()) {
    // Works:
    // while let Some(()) = { let mut b = a.borrow_mut(); foo(&mut *b) } {
        println!("{}", *a.borrow());
    }
}

The RefMut seems to outlive the while let block, instead of just the right expression.

The same happens if you put it in a block, like this:

while let Some(()) = { foo(&mut *a.borrow_mut()) } {

Same problem with if let.

[steveklabnik]

/cc @rust-lang/lang

[jonas-schievink]

I blame match desugaring, as always ;)

[pnkfelix]

This is not a if let or while let issue. You can see the same supposed misbehavior with a direct match:

use std::rc::Rc;
use std::cell::RefCell;

fn foo(a: &mut u32) -> Option<()> {
    if *a < 10 { *a += 1; Some(()) } else { None }
}

fn main() {
    let a = Rc::new(RefCell::new(4));
    loop {
        match foo(&mut *a.borrow_mut()) {
        // works:
        // match { let mut b = a.borrow_mut(); foo(&mut *b) } {
            Some(()) => { println!("{}", *a.borrow()); }
            None => break,
        }
    };
}

I think this is an rvalue-lifetimes issue.

(Furthermore, I think this is expected behavior, but @nikomatsakis is more expert on these matters than I...)

[nikomatsakis]

On Tue, Jan 12, 2016 at 08:28:28AM -0800, Felix S Klock II wrote:

(Furthermore, I think this is expected behavior, but @nikomatsakis is more expert on these matters than I...)

Another way to make the error go away is to change to match { let x = foo(&mut *a.borrow_mut()); x }. I agree this
is the "expected behavior", though it is a common footgun with
RefCell in particular. That is, you are best off always using
borrow expressions like this with a let (as I showed above, though
probably not in a nested block), since otherwise the borrow is held
for the entire match. Not sure if it would be possible to tweak the
rules to avoid this problem; I suspect it'd break code, but we'd have
to experiment to know for sure.

[bvssvni]

@nikomatsakis Thanks for the tip!

[arielb1]

We got to have some centralized place to track all annoyances with temporary destruction order rather than leaving them laying around in issues.

[steveklabnik]

triage: still an issue, even with NLL

[Mark-Simulacrum]

I'm going to close in favor of #15023 which is maybe not a great issue for this but seems to fit the bill of "temporary lifetimes are sometimes not quite what one would want".