Tracking Issue for RFC 3137: let-else statements

[joshtriplett]

This is a tracking issue for RFC 3137: let-else statements.
The feature gate for the issue is #![feature(let_else)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (Introduce let...else #87688)
• Adjust documentation: reference PR at Document let else statements reference#1156
• Stabilization PR: Stabilize let else #93628

Unresolved Questions

• Readability in practice: Will let ... else { ... }; be clear enough to humans in practical code, or will some introducer syntax be desirable?
• Conflicts with if-let-chains: Does this conflict too much with the if-let-chains RFC or vice-versa? Neither this feature nor that feature should be stabilized without considering the other.
• Amount of special cases: Are there too many special-case interactions with other features?
• Grammar clarity: Does the grammar need to be clarified? This RFC has some slightly unusual grammar requirements.

Implementation history

• Introduce let...else #87688 implemented let-else.
• Implement let-else type annotations natively #89841 adds support for type annotations in let-else (let x: Type = ... else { ... })

[inquisitivecrystal]

Minor meta notes: the link to the RFC is broken and the F-let-else label is the wrong color. :)

This comment should probably be collapsed once they've been fixed.

[LeSeulArtichaut]

Is there already someone who wants to implement the RFC? Otherwise I could maybe take a stab at it

[camsteffen]

I volunteered on Zulip to implement a while ago and I have a start on it. @Fishrock123 are you still okay with me taking it since you were also interested?

[Fishrock123]

I'm interested but I'm clueless and pretty busy. I'd say you should just take it.

[matklad]

An interesting example which I didn't see come up in the RFC text/thread (quick search for mut). In today's Rust, let-else won't work for a case of updating variables. An example here is computing a path in a graph after DFS returns a map of parents:

let parents: HashMap<u32, u32> = dfs();
let mut curr: u32 = 0;
let mut path: Vec<u32> = Vec::new();
loop {
    path.push(curr);
    let Some(&curr) = parents.get(curr) else { break }
}

Here, let won't re-bind curr, it'll shadow it instead.

Just as an observation, Kotlin-style elvis operator would avoid this issue, as it doesn't require a pattern:

let parents: HashMap<u32, u32> = dfs();
let mut curr: u32 = 0;
let mut path: Vec<u32> = Vec::new();
loop {
    path.push(curr);
    curr = *(parents.get(curr) ?: break);
}

[joshtriplett]

On Wed, Aug 18, 2021 at 04:35:50AM -0700, Aleksey Kladov wrote: An interesting example which I didn't see come up in the RFC text/thread (quick search for `mut`). In today's Rust, `let-else` won't work for a case of rebinding variables. An example here is computing a path in a graph after DFS returns a map of parents: ```rust let parents: HashMap<u32, u32> = dfs(); let mut curr: u32 = 0; let mut path: Vec<u32> = Vec::new(); loop { path.push(curr); let Some(&curr) = parents.get(curr) else { break } } ``` Here, `let` won't re-bind curr, it'll shadow it instead

I wouldn't *ever* expect `let` to change what an existing location refers to, only to make a new binding and shadow any previous binding.

[matklad]

Ah, indeed, I am confused, I was thinking about #71126, which is a different feature, I'll edit my comment.

[matklad]

Hypothetically, we can allow the following (else without let):

let parents: HashMap<u32, u32> = dfs();
let mut curr: u32 = 0;
let mut path: Vec<u32> = Vec::new();
loop {
    path.push(curr);
    Some(&curr) = parents.get(curr) else { break }
}

This would be a natural combination of let-else and #71126. While #71126 is still unstable, it might be worth is to think about the interactions between the two. Will the above example just work, or are there any problems with it?

[camsteffen]

I also mentioned this in the RFC. Probably no technical limitation but just readability concerns. I think we can safely wait until let-else and destructuring-assignment have matured before expecting them to procreate (forgive me).