"else match" Extending Conditional Syntax

[scottmcm]

This is a very old idea. The first version of it I found is from 2016 If-else could allow omitting braces on the else · Issue #1616 · rust-lang/rfcs · GitHub and then someone wrote an RFC that was rejected in 2017 Add 'else match' blocks to if expressions. by phoenixenero · Pull Request #1712 · rust-lang/rfcs · GitHub

Has anything materially changed since then? Nothing comes to mind to me.

@Igor743646

The proposed extension addresses a fundamental inconsistency: while if let enjoys first-class support in both primary and secondary conditional positions, the more powerful match expression is artificially constrained to require block nesting when following an else clause.

Reusing an 8-year old post to address this: https://github.com/rust-lang/rfcs/pull/1712#issuecomment-277857697.

@Igor743646

Proposed syntax:

if condition {
    handle_positive();
} else match value {
    Pattern1 => handle_pattern1(),
    Pattern2 => handle_pattern2(),
}

If it's something that can't just be written as

match value {
    _ if condition => handle_positive(),
    Pattern1 => handle_pattern1(),
    Pattern2 => handle_pattern2(),
}

then the extra nesting is maybe even good.

@Igor743646

The core benefit of else match - eliminating block nesting while maintaining existing safety guarantees - justifies its inclusion without expanding into these more complex territory.

If this was sufficient justification to add it, it's also be sufficient justification to add else for and else loop and a whole bunch of other stuff -- even things like loop for. So I think you need a much stronger reason that else match is special, or you do need to argue that those other extensions would also be similarly good and probably worth doing to.

@Igor743646

match options will technically be expanded in the if let construct

I don't think that the syntactic version of this is what people would want in if let.

More likely, to me, if there was going to be an else match it'd be a typestate-style thing so that you can do

let Ordering::Equal = … stuff …
else match {
    Ordering::Less => …,
    Ordering::Greater => …,
};

where it's not a syntactic contraction, but an extended whole-construct thing where the exhaustiveness checking is aware of both the let pattern and the match patterns, so you can handle the remainder of the value that was pattern-matched in a nice way that's not possible with today's let-else.

Just removing an extra set of braces in there doesn't seem worth bothering at all, but giving new expressivity might be.

(That said, it's still just convenience, as it's already possible with plain match, so it'd need a survey showing in real code that it'd be widely applicable, not just "well it sounds nice" or "it happens sometimes".)