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 { ... })

[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);
}

[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).

[Fishrock123]

Ah, I seem to have missed that thing about destructuring_assignment, yes that seems like a future possibility, with the above mentioned caveats.

[Fishrock123]

@joshtriplett #87688 has been merged, can you tick off "implement the RFC"?

[Fishrock123]

@camsteffen @cjgillot did the implementation answer the "Grammar clarity" question at all?

[camsteffen]

did the implementation answer the "Grammar clarity" question at all?

See expr_trailing_brace - I think the "slightly unusual grammar requirements" are contained there.

[Fishrock123]

My understanding of the state of implementation is:

• Working on nightly under a flag (I actually have yet to try it! I've been busy)
• Flagged for compiler perf investigation Introduce let...else #87688 (comment)

[nikomatsakis]

@Fishrock123 cool! Once you've had a chance to test, we should consider moving to feature complete status and writing a blog post as a way to get more feedback. =)

[nagisa]

#89688 is a blocker for a stabilization. Without this fixed, our implementation does not match the behaviour as prescribed by the RFC.