# Rust Release Changelog - 1.95.0

## Overview

Hi, hello.

We are

Pete LeVasseur
Tyler Mandry
Cameron Dershem

from the relatively new Rust [Content Team](https://rust-lang.org/governance/teams/#team-content). You may not have heard of us by now and that's a little on us. Our team was founded to help explore and publish more of what's happening within and from the prospective of the Rust Project itself.

Recently we've observed many questions regarding things that we've taken for granted that everyone knew about Rust. This lead us to realize that most everyone on our team has been around since the early days when it was easy to keep up with everything in the Project, but as we grow, it's completely unreasonable to expect anyone to be able to 'catch up' with more than a decade of knowledge.

Our hope is to use this series to both surface voices within the Project and to give the community more insight into how things work. We plan to release one video every 6 weeks coinciding with Rust's release cadence.

Some topics we're hoping to cover:

- What is Rust's release cadence?
- why is it like that?
- What the heck is the Release Train?
- Who decides what goes in a release?
- What's a support tier?
- How do Rust releases get tested?
- What can go wrong?
- Why is there a patch release!?!!
- What can we do to prevent patch releases?
- When will Rust release 2.0?
- How does [releases.rs](https://releases.rs) work and who runs it?

## Changelog Overview

**Note**: We are recording this on Wednesday, April 15th, 2026. The official release doesn't come out until Thursday. Everything is subject to change until the actual release is out. How and why this is will be the subject of a future episode.

https://releases.rs/docs/1.95.0/

## irrefutable_let_patterns

if let x = foo() { }
if let Some(x) = foo() { }

if let err_code = foo() && err_code != 0 {
    println!("Error: {err_code}");
}

## `if let` guards

One of Rust's most powerful features is the `match` expression. It allows you to do pattern matching on a value, and it has fancy features like exhaustiveness checking, nested patterns, and "match ergonomics" for looking through references.

Rust 1.95 adds if-let guards, which are best demonstrated through an example. My brain is broken in such a way that in my spare time I've been writing a window manager for macOS in Rust. I have an example from that here.

Often in systems programming we have to handle errors appropriately. Sometimes the appropriate thing to do is to log.

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(e) => {
        log_error(e);
        None
    }
}

This is a simple match expression that gets the window id for a window from a system API. If it encounters an error it logs the error and yields None.

Simple enough. So what happens if we want to ignore certain error conditions?

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(_) if element.role() == Role::SCROLL_AREA {
        // Desktop is special; ignore.
        None
    }
    Err(e) => {
        log_error(e);
        None
    }
}

What I might want to write is this. If the window says it's a scroll area then it's not actually a window, it's the special desktop window, and that's an expected case that we don't have to log.

The problem is, `element.role()` doesn't return a role, it returns a *Result* of a role with some error type that doesn't implement equality comparisons. So when I implemented this a year ago...

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(e) => {
        if let Ok(role) = element.role() {
            if role == Role::SCROLL_AREA {
                // Desktop is special; ignore.
                return None;
            }
        }

        log_error(e);
        None
    }
}

...my code looked something like this. Note the use of early return, which means this match needs to go in its own helper function.

(Optional question: Couldn't you just pattern match using the SCROLL_AREA value inside the `Ok` pattern?)
(Answer: No, because the value is actually a special system string type that's not always UTF-8, and therefore doesn't support pattern matching with Rust string literals. Gross, but this happens all the time in real code.)

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(e) => {
        if let Ok(role) = element.role()
            && role == Role::SCROLL_AREA
        {
            // Desktop is special; ignore.
            return None;
        }

        log_error(e);
        None
    }
}

Rust 1.88 in April 2025 stabilized if-let chains, which allow me to remove one level of nesting. But notice we still have to rely on early-return to make this ergonomic, or use an else branch.

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(e) => {
        if let Ok(role) = element.role()
            && role == Role::SCROLL_AREA
        {
            // Desktop is special; ignore.
            None
        } else {
            log_error(e);
            None
        }
    }
}

Both of these make this logic harder to read than it has to be. (The actual logic is more complicated than this.) There is another strategy I tried, which is to use result and option combinators like `or_else` and `.ok()`, but those weren't much better.

So this is a bit of a papercut, obviously not the end of the world, but one of those places where it seems like there should be something there in the language and there just isn't. I could have written the match the way I wanted to if I could use a regular `if` guard. But I have to use pattern matching. Rust has `if let` for that, but `if let` doesn't compose with `match`. Until now.

Now, in Rust 1.95, I can flatten the entire into one level and the special case can fit on a single line using if-let guards:

match get_window_id(&element) {
    Ok(id) => Some(id),
    Err(_)
        if let Ok(role) = element.role()
            && role == Role::SCROLL_AREA =>
    {
        // Desktop is special; ignore.
        None
    }
    Err(e) => {
        log_error(e);
        None
    }
}

This is much nicer, and I no longer need a helper function or multiple levels of nesting.

Before I kind of felt like Rust was punishing me for doing the right thing: Being careful about handling error conditions correctly. But now I feel like it has my back, and better supports the kind of complicated logic you often find in systems programming.

Note: This is not only useful for error handling. The original RFC had an example of using this to parse terminal escape codes.

This is also an example of a principle of language design called composition: When we introduce a feature in the core language, it should *compose* cleanly with all the other language features where it naturally makes sense.

In Rust we sometimes defer making all features of a language compose with one another in the interest of getting something out there for people to use. This was the case with `if let`, and then if let chains. Those didn't compose with match guards even though they were an obvious place. Now we have if let chains in match guards, which rounds out the picture. It makes Rust a better language for writing intricate logic that stands up to the complexity of production software systems.

##

## Outro

Please let us know if you found this useful. We'd love any feedback. We're also very open to topic ideas that you'd like us to explore. If you think you are or know someone that we should have on as a guest, please reach out too!

Thank you for watching. We'll see you in 6 weeks!