destructuring assignment and let else

[lcnr]

#![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 };
    }
}

results in

error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found keyword `else`
  --> src/lib.rs:11:36
   |
11 |         Foo::Nested(value) = value else { break };
   |                                    ^^^^ expected one of 8 possible tokens

i.e. a general parser error. This should either be supported and compile, or get a better error.

[Fishrock123]

You are not using let … else. The syntax you provided is invalid and should be invalid.

Adding a let to that destructuring assignment makes it work as intended: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=65cdac15a8c224569ab6415bfadcb990

[rpjohnst]

@Fishrock123 There's a pre-existing feature distinct from let bindings called "destructuring assignment": #71126

This issue is about the question of how let else and destructuring assignment should (or should not) interact, not just a syntax error.

[est31]

I think refutable patterns is where the symmetry breaks down between let and assignments, as let must have a diverging else clause while an else clause for destructuring assignments with refutable patterns does not make sense. See #93628 (comment) where I suggest adoption of a destructuring assignment construct introduced by maybe so that it's obvious to readers that the assignment doesn't neccessarily happen. maybe 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.

[lcnr]

I think refutable patterns is where the symmetry breaks down between let and assignments, as let must have a diverging else clause while an else clause for destructuring assignments with refutable patterns does not make sense.

Why that? The reasoning behind adding something like maybe seems to be the same for let-else where we explicitly decided against adding anything apart from the else.

[memoryruins]

There were considerations about these two features interacting in the let_else tracking issue #87335 (comment) and the rfc rust-lang/rfcs#3137 (comment), but discussion was paused for when the features matured a bit, which appears to be now. @matklad if you've had more thoughts about this since that comment, this appears to be the place for it ^^

[est31]

I think refutable patterns is where the symmetry breaks down between let and assignments, as let must have a diverging else clause while an else clause for destructuring assignments with refutable patterns does not make sense.

Why that? The reasoning behind adding something like maybe seems to be the same for let-else where we explicitly decided against adding anything apart from the else.

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 else 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 let, because let 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 else as introducer syntax mainly if you are coming from let else in mind. I think if you design it as its feature of its own right, something like maybe seems more natural. One can think about optionally supporting else clauses for maybe even, but it should not be the primary identifying feature of refutable destructuring assignments.

[rpjohnst]

There is no need for the else 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).

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.

I meant that you arrive at else as introducer syntax mainly if you are coming from let else in mind.

Not at all. When let first got refutable pattern support, it was added via if, and only now extended to else. That's the symmetry that refutable destructuring assignment would need to fit into. A new standalone construct like maybe Some(foo) = bar.get(42) doesn't.

[est31]

There is no need for the else 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).

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.

I meant "need" in the sense of a hard requirement for else clauses. There is no need to require else clauses for assignments (outside of wanting introducer syntax for which else is a suboptimal solution).

I meant that you arrive at else as introducer syntax mainly if you are coming from let else in mind.

Not at all. When let first got refutable pattern support, it was added via if, and only now extended to else. That's the symmetry that refutable destructuring assignment would need to fit into. A new standalone construct like maybe Some(foo) = bar.get(42) doesn't.

Oh I see where you are coming from. I'm not convinced that this is the better way of looking at it. if let has always had support for else for example.

[rpjohnst]

There is no need to require else clauses for assignments (outside of wanting introducer syntax for which else is a suboptimal solution).

I don't think there's a need to require else clauses in particular, but I do think there should always be an if or and else 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 maybe seem to be the odd one out.

[lcnr]

In refutable patterns, there is a default behaviour that destructuring assignments can fall back to, which is not doing the assignment.

I don't think that this is always true, consider the following:

struct Foo(i32);

fn main() {
    let x;
    {
        Foo(x) = Foo(1);
    }
    println!("x");
}

[joshtriplett]

I think it makes sense to consider the possibility of destructuring assignment with an else. 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 else have a disadvantage and higher bar than let-else does, because let ... else has the let as an introducer for the type of statement, while assignments do not, making the else 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 while let, but for want of a do-while-like construct.

[est31]

I've filed a PR to issue a dedicated error: #94211