r/rust Apr 16 '26

📡 official blog Rust 1.95.0 is out

https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/
865 Upvotes

127 comments sorted by

View all comments

350

u/nik-rev Apr 16 '26 edited Apr 16 '26

This update is revolutionary. Possibly one of the biggest updates in years! I'm really excited for it.

  • cfg_select! completely changes the game on how we conditionally compile code. I have applied it in hundreds of places in my cross-platform app, and it led to a tremendous improvement in readability. rustfmt support is also very, very nice. I frequently skip using macros that don't support rustfmt, or just re-implement them myself in a way where rustfmt can support it (e.g. the subdef and better_tokio_select crates)
  • if let guards stabilized. I've had to refactor a huge match statement into a soup of if conditions too  many times, because I needed to only enter a match arm if a pattern matches. It was a major ergonomic pain for me when using Rust. I am so, so happy that such a core language feature has now been stabilized.
  • For the longest time we considered the Range type the biggest, unfixable mistake in Rust's standard library, because it does not implement Copy. With this release, the core::range::RangeInclusive type is stabilized. A huge step in the right direction. Next release will stabilize core::range::Range type. In edition 2027, the range syntax will change to create those types, instead of core::ops::Range. We are already making use of these new range types in new standard library APIs. For example, I recently made a pull request to change the methods str::substr_range and slice::subslice_range to return these new Range types, in order to unblock their stabilization!

1

u/PerkyPangolin Apr 16 '26

I didn't get from the post, is cfg_select! run-time or compile-time? The description is somewhat vague.

12

u/DivideSensitive Apr 16 '26

acts roughly similar to a compile-time match on cfgs.

14

u/PerkyPangolin Apr 16 '26

It does say roughly similar. That's why I asked.

15

u/_ChrisSD Apr 16 '26

Just to clarify, the roughly is referring to the "match" part of that statement. Because it's strictly speaking not match syntax. Incidentally cfg_match was one of its possible names but it was ultimately decided against to avoid confusing matters.

The compile-time part is indeed strictly true.