Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: change the desugaring of if let to improve borrow checking #2068

Closed
mark-i-m opened this issue Jul 18, 2017 · 4 comments
Closed

Idea: change the desugaring of if let to improve borrow checking #2068

mark-i-m opened this issue Jul 18, 2017 · 4 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@mark-i-m
Copy link
Member

Related: rust-lang/rust#28449

Currently if let desugars to a match with guards. Using the example from the related post:

let mut f = Some(1);
if let Some(a) = f {
    bar();
} else if f.as_mut().is_some() {
    baz();
}

Desugars to

match f {
    Some(a) => {bar();}
    _ if f.as_mut().is_some() {baz();}
    _ => {}
}

However, this leads to f being borrowed in the else if which is truly annoying. Instead, I propose the following desugaring:

    if match f {Some(_) => true, _ => false } {
         let Some(a) = f;
         { bar(); } 
    } else if f.as_mut().is_some() {
        baz();
    }

Which (I believe) does not suffer from the same problem.

One unanswered question is: does non-lexical lifetimes solve this?

@durka
Copy link
Contributor

durka commented Jul 20, 2017

The proposed desugaring evaluates f twice.

@mark-i-m
Copy link
Member Author

Oh, that's true... But I believe it is easily fixed by just evaluating once beforehand, right?

@Ixrec
Copy link
Contributor

Ixrec commented Jul 22, 2017

I'm pretty sure non-lexical lifetime will solve this, since the code this desugars to is essentially the same as the classic example of trying to insert a value into a map if it's not already in the map. Niko discusses that example both on his blog way back in April and in his recent RFC for NLL.

@mark-i-m
Copy link
Member Author

@Ixrec Ah, thanks. I think NLL definitely subsumes this idea...

@Centril Centril added the T-lang Relevant to the language team, which will review and decide on the RFC. label Feb 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants