Change:
<ins> #![feature(let_else)] #[derive(Debug)] enum Foo { Done, Nested(Option<&'static Foo>), } fn walk(mut value: &Foo) { loop { println!("{:?}", value); &Foo::Nested(Some(value)) = value else { break }; //~ ERROR invalid left-hand side of assignment //~^ERROR <assignment> ... else { ... } is not allowed } } fn main() { walk(&Foo::Done); } </ins>

Discussion:
results in i.e. a general parser error. This should either be supported and compile, or get a better error.
You are not using . The syntax you provided is invalid and should be invalid. Adding a to that destructuring assignment makes it work as intended:
There's a pre-existing feature distinct from bindings called "destructuring assignment": This issue is about the question of how and destructuring assignment should (or should not) interact, not just a syntax error.
I think refutable patterns is where the symmetry breaks down between and assignments, as must have a diverging clause while an clause for destructuring assignments with refutable patterns does not make sense. See where I suggest adoption of a destructuring assignment construct introduced by so that it's obvious to readers that the assignment doesn't neccessarily happen. is not a keyword right now, but can be introduced at an edition boundary. if it's seen as valuable enough to have such sugar in the first place. When it comes to errors, I always side on having more helpful ones.
Why that? The reasoning behind adding something like seems to be the same for where we explicitly decided against adding anything apart from the .
There were considerations about these two features interacting in the tracking issue the rfc , but discussion was paused for when the features matured a bit, which appears to be now. if you've had more thoughts about this since that comment, this appears to be the place for it ^^
In refutable patterns, there is a default behaviour that destructuring assignments can fall back to, which is not doing the assignment. There is no need for the clause to diverge, in fact no need for the else clause at all (beyond having some syntax to make it obvious the assignment is not a given). While there is a strong need in the case of , because creates a binding.That's what I mean by breakdown of symmetry. There is symmetry for irrefutable patterns. With "does not make sense", which was probably a bit too strong, I meant that you arrive at as introducer syntax mainly if you are coming from in mind. I think if you design it as its feature of its own right, something like seems more natural. One can think about optionally supporting clauses for even, but it should not be the primary identifying feature of refutable destructuring assignments.
I wouldn't go quite that far- how do you detect whether the assignment occurred?

Refutable patterns have a control flow component that is often useful. You'd still want to be able to take different branches based on whether the pattern matched. Not at all. When first got refutable pattern support, it was via , and only now extended to . That's the symmetry that refutable destructuring assignment would need to fit into. A new standalone construct like doesn't.
I meant "need" in the sense of a hard requirement for clauses. There is no need to require else clauses for assignments (outside of wanting introducer syntax for which else is a suboptimal solution). Oh I see where you are coming from. I'm not convinced that this is the better way of looking at it. has always had support for for example.
I don't think there's a need to require else clauses in particular, but I do think there should always be an or and or some sort of control flow, rather than ever dropping the control flow silently. That's the place I'm coming from that makes standalone seem to be the odd one out.
I don't think that this is always true, consider the following:
I think it makes sense to consider the possibility of destructuring assignment with an . I also think such a combination needs to pull its own weight, with use cases independent of let-else, that themselves come across much more clearly than alternatives. And in particular, I think destructuring assignments with have a disadvantage and higher bar than let-else does, because has the as an introducer for the type of statement, while assignments do not, making the feel more unexpected. As a result, my first instinct is to document this as not supported, and perhaps improve error messages to steer people towards let-else. The specific example that opened this thread seems very close to , but for want of a do-while-like construct.
I've filed a PR to issue a dedicated error: