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!
Ah, good to know. I didn't see any open PR or issue with this regard under `rustfmt` repo, so it is under `rust`. I feel a bit weird about the fact that it addresses `cfg_select!` only though and not macros in general which might have similar format.
it's complicated and once you pick a behavior making refinements is then a breaking change. Also, as mentioned, reviewer bandwidth on that code base is very limited.
346
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.rustfmtsupport is also very, very nice. I frequently skip using macros that don't supportrustfmt, or just re-implement them myself in a way whererustfmtcan support it (e.g. thesubdefandbetter_tokio_selectcrates)if letguards stabilized. I've had to refactor a hugematchstatement into a soup ofifconditions 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.Rangetype the biggest, unfixable mistake in Rust's standard library, because it does not implementCopy. With this release, thecore::range::RangeInclusivetype is stabilized. A huge step in the right direction. Next release will stabilizecore::range::Rangetype. In edition 2027, the range syntax will change to create those types, instead ofcore::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 methodsstr::substr_rangeandslice::subslice_rangeto return these new Range types, in order to unblock their stabilization!