What's your 2026 wish-list for Rust?

1

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!

11 Likes
2

Build-std is the number one feature I want.

13 Likes
3

I still have a project of mine which would greatly benefit from contexts (for passing a generic parameter to a hash impl) but this thing is not even half-cooked yet.

2 Likes
4

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<OsStr> and the as_ref() function cannot be called in const eval.

40 Likes
5 
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");       
        }
   }
}
8 Likes
6

New trait solver stabilized. Basically every other feature is blocked on it

27 Likes
7

I'd like to have some more documentation and features around cargo-vet for supply chain management.

4 Likes
8

A stable Polonius, though I know it may take longer. :slight_smile:

15 Likes
9

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.

8 Likes
10

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.

16 Likes
11
  • Next solver (tracking issue) for feature unblocking reasons
    • TAIT (and friends I guess but TAIT is the main one)
  • Polonius alpha
  • try_as_dyn could be pretty big but I don't have a feel for how experimental it is
  • f128 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).

15 Likes
12

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?

13

It lets you check some bounds at run time, which basically affords a subset of specialization.

fn foo<T: Trait>(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.

13 Likes
14

Some things already mentioned (more const!!!), and variadic generics

2 Likes
15

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.

5 Likes
16

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.

17

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.

8 Likes
18

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.

5 Likes
19

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.

3 Likes
20

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.