# What's your 2026 wish-list for Rust? **URL:** \ **Category:** uncategorized\ **Created:** [December 31, 2025, 3:00pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259 "2025-12-31T15:00:26Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![blonk](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/blonk/32/38259_2.png) [@blonk](https://users.rust-lang.org/u/blonk)\ **Post date:** [December 31, 2025, 3:00pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/1 "2025-12-31T15:00:26Z")
Whether it's pie-in-the-sky, or something that's currently being stabilized -- what are you hoping to see in Rust in 2026 (in particular due to experiences in 2025)? In 2025 I've run into a surprising amount of needing custom `Result`-like types, which has caused me to be unable to use the `?` operator in places where it would make the code much more friendly on the eyes. I would love to see try-v2, with the ability to define custom `?` conversions, stabilized. Not sure if it's at the very top of the list, but if it isn't -- it's close. I also want async drop. There are workarounds that I'm not completely unsatisfied with, so this isn't as big of deal as I used to think it was. But it would be nice. A less footgun'y async `select!` would be nice, but I have no idea what that would look like. And finally I want lots of stabilizations in std. Not a week goes by where I don't run into something I want/need in std only to discover that it's nightly only. Looking forward to seeing what 2026 brings! ---
**Author:** ![Vorpal](https://avatars.discourse-cdn.com/v4/letter/v/aca169/32.png) [@Vorpal](https://users.rust-lang.org/u/Vorpal)\ **Post date:** [December 31, 2025, 3:02pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/2 "2025-12-31T15:02:37Z")
Build-std is the number one feature I want. ---
**Author:** ![bestouff](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/bestouff/32/5016_2.png) [@bestouff](https://users.rust-lang.org/u/bestouff)\ **Post date:** [December 31, 2025, 4:20pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/3 "2025-12-31T16:20:39Z")
I still have a project of mine which would greatly benefit from [contexts](https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/) (for passing a generic parameter to a hash impl) but this thing is not even half-cooked yet. ---
**Author:** ![kpreid](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/kpreid/32/22420_2.png) [@kpreid](https://users.rust-lang.org/u/kpreid)\ **Post date:** [December 31, 2025, 4:44pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/4 "2025-12-31T16:44:33Z")
Const trait impls will remove so many restrictions on what can be done at compile time and put into a `const`. Hardly a week goes by where I don’t bump into a limitation that comes down to const trait impls — for example, `Path::new("/")` looks like a perfectly good constant expression, but it isn’t, because `Path::new` takes `AsRef` and the `as_ref()` function cannot be called in const eval. ---
**Author:** ![thisisnotatrash](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/thisisnotatrash/32/50572_2.png) [@thisisnotatrash](https://users.rust-lang.org/u/thisisnotatrash)\ **Post date:** [December 31, 2025, 7:06pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/5 "2025-12-31T19:06:48Z")
```rust pub enum Test { One, Two, Three, Four } fn main() { let obj = Test::One; match obj { max_two @ (Test::One | Test::Two) => match max_two { Test::One => println!("one"); Test::Two => println!("two"); // NO ERROR HERE } Test::Three | Test::Four => { println!("three or four"); } } } ``` ---
**Author:** ![Ddystopia](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/ddystopia/32/34903_2.png) [@Ddystopia](https://users.rust-lang.org/u/Ddystopia)\ **Post date:** [December 31, 2025, 7:29pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/6 "2025-12-31T19:29:27Z")
New trait solver stabilized. Basically every other feature is blocked on it ---
**Author:** ![conqp](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/conqp/32/42559_2.png) [@conqp](https://users.rust-lang.org/u/conqp)\ **Post date:** [December 31, 2025, 8:19pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/7 "2025-12-31T20:19:02Z")
I'd like to have some more documentation and features around `cargo-vet` for supply chain management. ---
**Author:** ![Redglyph](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/redglyph/32/27961_2.png) [@Redglyph](https://users.rust-lang.org/u/Redglyph)\ **Post date:** [December 31, 2025, 8:28pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/8 "2025-12-31T20:28:36Z")
A stable Polonius, though I know it may take longer. 🙂 ---
**Author:** ![scottmcm](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/scottmcm/32/4286_2.png) [@scottmcm](https://users.rust-lang.org/u/scottmcm)\ **Post date:** [December 31, 2025, 8:31pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/9 "2025-12-31T20:31:09Z")
> [@blonk](#): > > I would love to see try-v2, with the ability to define custom `?` conversions, stabilized. Not sure if it's at the very top of the list, but if it isn't -- it's close. Make sure you post an experience report of using it (and try blocks) on the corresponding tracking issues, if you haven't already. There's lots of questions open around how the polarities of the traits should be, how interoperability between different try types and try families should work, and such, so the more "here's what I want to do and here's how it went" the better -- especially if it's not just another "well I'm 99% of the way there with just `Result<_, MyType>`" case. ---
**Author:** ![ZiCog](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/zicog/32/12216_2.png) [@ZiCog](https://users.rust-lang.org/u/ZiCog)\ **Post date:** [December 31, 2025, 8:41pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/10 "2025-12-31T20:41:07Z")
I wish that Rust does not sprout any more syntax or semantics unless they are really essential. I understand the Linux kernel and embedded folks have some pressing needs. I worry that as Rust attracts more users, coming from all kind of different language backgrounds, there is growing pressure to add this syntax or that semantic or whatever just because somebody misses it from their previously fav language. I don't want Rust to go down the C++ road piling on ever more complication. Happy New Year all. ---
**Author:** ![quinedot](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/quinedot/32/17693_2.png) [@quinedot](https://users.rust-lang.org/u/quinedot)\ **Post date:** [December 31, 2025, 9:27pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/11 "2025-12-31T21:27:19Z")
- [Next solver](https://github.com/rust-lang/rust-project-goals/issues/113) ([tracking issue](https://github.com/rust-lang/rust/issues/107374)) for feature unblocking reasons - [TAIT](https://github.com/rust-lang/rust/issues/63063) (and friends I guess but TAIT is the main one) - [Polonius](https://github.com/rust-lang/rust-project-goals/issues/118) alpha - [`try_as_dyn`](https://github.com/rust-lang/rust/issues/144361) could be pretty big but I don't have a feel for how experimental it is - [`f128`](https://github.com/rust-lang/rust/issues/116909) so I can stop missing `f80` every blue moon maybe? There's other significant things but I doubt they'll land next year. There are smaller `std` things that are covered by crates (drop guards, non-poisoning mutex, byte strings). ---
**Author:** ![throwable-one](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/throwable-one/32/31948_2.png) [@throwable-one](https://users.rust-lang.org/u/throwable-one)\ **Post date:** [December 31, 2025, 11:42pm UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/12 "2025-12-31T23:42:50Z")
> [@quinedot](#): > > - [`try_as_dyn`](https://github.com/rust-lang/rust/issues/144361) could be pretty big but I don't have a feel for how experimental it is What are use cases, by the way? We already have virtual methods and tagged unions (aka enums) in Rust, why whould one need to check the type in runtime? ---
**Author:** ![quinedot](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/quinedot/32/17693_2.png) [@quinedot](https://users.rust-lang.org/u/quinedot)\ **Post date:** [January 1, 2026, 12:31am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/13 "2026-01-01T00:31:10Z")
It lets you check some bounds at run time, which basically affords a subset of specialization. ```rust fn foo(t: T) { // The branch here is expected to be eliminated when monomorphized. if let Some(dt) = try_as_dyn::<_, dyn SubTrait>(&t) { // Do something special. `SubTrait` could even be // a marker trait that verifies some invariants required // for `unsafe`, or it could supply some supplemental // data; you need not use dynamic dispatch specifically // (though of course you can). } else { // Do the thing that works for all `T: Trait` } } ``` If you have a closed set of implementations, you could use an `enum` instead, but not if you have an open set. ---
**Author:** ![HQ2000](https://avatars.discourse-cdn.com/v4/letter/h/a88e4f/32.png) [@HQ2000](https://users.rust-lang.org/u/HQ2000)\ **Post date:** [January 1, 2026, 12:32am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/14 "2026-01-01T00:32:20Z")
Some things already mentioned (more const!!!), and variadic generics ---
**Author:** ![Kyllingene](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/kyllingene/32/33899_2.png) [@Kyllingene](https://users.rust-lang.org/u/Kyllingene)\ **Post date:** [January 1, 2026, 1:02am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/15 "2026-01-01T01:02:03Z")
My big wish is for decl macros 2.0 to finally see a big push, but I'm not too hopeful. Less niche but equally huge would be GCE, especially with const traits. ---
**Author:** ![throwable-one](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/throwable-one/32/31948_2.png) [@throwable-one](https://users.rust-lang.org/u/throwable-one)\ **Post date:** [January 1, 2026, 1:03am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/16 "2026-01-01T01:03:02Z")
> [@quinedot](#): > > It lets you check some bounds at run time, which basically affords a subset of specialization. Thank you, I'd expect dynamic dispatch to be used here, but I am somewhat biased, because I've seen too may runtime instance checks in Java and almost always it was a fragile solution. Although it can be valid for some cases. ---
**Author:** ![user16251](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/user16251/32/30527_2.png) [@user16251](https://users.rust-lang.org/u/user16251)\ **Post date:** [January 1, 2026, 2:08am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/17 "2026-01-01T02:08:23Z")
I would like the allocator API to be stabilized. But other than that, I don't want any new features. I want faster compile times. I want all the soundness holes in Rust to be closed, even if this causes some churn in my own code. I would like better debugger support. ---
**Author:** ![ryanavella](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/ryanavella/32/47437_2.png) [@ryanavella](https://users.rust-lang.org/u/ryanavella)\ **Post date:** [January 1, 2026, 4:57am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/18 "2026-01-01T04:57:53Z")
`gen_blocks` is on my wish list. Some iterators are more intuitively expressed in a yield/push style, and if you are forced to write them in the pull paradigm it often means handrolling your own error-prone state machines. ---
**Author:** ![Redglyph](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/redglyph/32/27961_2.png) [@Redglyph](https://users.rust-lang.org/u/Redglyph)\ **Post date:** [January 1, 2026, 9:59am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/19 "2026-01-01T09:59:57Z")
> [@ZiCog](#): > > I worry that as Rust attracts more users, coming from all kind of different language backgrounds, there is growing pressure to add this syntax or that semantic or whatever just because somebody misses it from their previously fav language. Isn't that how languages evolve, by taking interesting bits from others? But I see what you mean, and I agree that each new element should be thoroughly vetted. From what I understand, and from the process and the time it takes, I think that's thankfully the case. ---
**Author:** ![ZiCog](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/zicog/32/12216_2.png) [@ZiCog](https://users.rust-lang.org/u/ZiCog)\ **Post date:** [January 1, 2026, 11:00am UTC](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259/20 "2026-01-01T11:00:53Z")
> [@Redglyph](#): > > I think that's thankfully the case. That is very good. However the same can be said of C++ with its ISO standard and its design committee. Which has not stopped C++ becoming an unholy mess of complexity. [Next page](https://users.rust-lang.org/t/whats-your-2026-wish-list-for-rust/137259.md?page=2)