# "else match" Extending Conditional Syntax

**URL:** <https://internals.rust-lang.org/t/else-match-extending-conditional-syntax/23780>\
**Category:** language design\
**Created:** [November 28, 2025, 3:59pm UTC](https://internals.rust-lang.org/t/else-match-extending-conditional-syntax/23780 "2025-11-28T15:59:21Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\
**Post date:** [November 28, 2025, 8:19pm UTC](https://internals.rust-lang.org/t/else-match-extending-conditional-syntax/23780/8 "2025-11-28T20:19:43Z")

</div>

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](https://github.com/rust-lang/rfcs/issues/1616) 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](https://github.com/rust-lang/rfcs/pull/1712#issuecomment-277508882)

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](https://github.com/rust-lang/rfcs/pull/1712#issuecomment-277857697).

> [@Igor743646](#):
>
> **Proposed syntax:**
> 
> ```rust
> if condition {
> handle_positive();
> } else match value {
> Pattern1 => handle_pattern1(),
> Pattern2 => handle_pattern2(),
> }
> 
> ```

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

```rust
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

```rust
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".)

---

_[View the full topic](https://internals.rust-lang.org/t/else-match-extending-conditional-syntax/23780)._