# Rust 2023 roadmap review

## Prior post

https://blog.rust-lang.org/inside-rust/2022/04/04/lang-roadmap-2024.html

## Flatten the (learning) curve

| Thing | Short update |
| --- | --- |
| Polonius | lqd + nikomatsakis vaguely planning |
| Implied bounds | no real progress, types team is working on improved trait solver |
| let else | **stabilized!** |
| [let-chains](https://github.com/rust-lang/rust/issues/53667) | nightly support, may be stalled |
| ["Type alias" impl Trait](https://rust-lang.github.io/impl-trait-initiative/explainer/tait.html) | pending stabilization |
| [Generic associated types](https://rust-lang.github.io/generic-associated-types-initiative/) | stabilized, but need follow-up work |
| Async fn in traits, static support | nightly support, need to address `Send` bounds |
| [Dyn upcasting coercion initiative](https://github.com/rust-lang/dyn-upcasting-coercion-initiative/issues/6) | landed impl work + RFC, need to stabilize |
| Async fn in traits, dyn support | need to finalize design

- **More precise analyses, less rigamarole:**
- Non-lexical lifetimes were a big stride forward, but the [polonius project](https://github.com/rust-lang/polonius/) promises to improve the borrow check's precision even more.
- [Implied bounds](https://github.com/rust-lang/rust/issues/44491) promise to remove a lot of copy-and-pasting of where clauses.
- **Express yourself more easily:**
- [let-else](https://github.com/rust-lang/rust/issues/87335) directly express the "match this variant or `return`/`continue`/etc" pattern.
- [let-chains](https://github.com/rust-lang/rust/issues/53667) allow you to express iterative refinement with a series of pattern-matches and conditionals
- ["Type alias" impl Trait](https://rust-lang.github.io/impl-trait-initiative/explainer/tait.html) permits APIs to name previously unnameable types. This is part of a larger effort to [expand impl Trait](https://rust-lang.github.io/impl-trait-initiative/).
- [Generic associated types](https://rust-lang.github.io/generic-associated-types-initiative/) allow traits to express a number of patterns (like "iterable") that the current trait system cannot handle. They are a particularly important foundational piece for async programming.
- **Improve async support:**
- We are working to support [async fns in traits](https://rust-lang.github.io/async-fundamentals-initiative/explainer/async_fn_in_traits.html), including both static dispatch and dyn dispatch.
- **Make `dyn Trait` more usable:**
- [Dyn upcasting coercion initiative](https://github.com/rust-lang/dyn-upcasting-coercion-initiative/issues/6): Allow upcasting `dyn trait` objects from `&dyn Subtrait` to `&dyn Supertrait`.
- The [async fn in traits](https://rust-lang.github.io/async-fundamentals-initiative/explainer/async_fn_in_traits.html) initiative is also extending dyn trait to support async fns and "return position impl Trait".

### Looking forward

Looking beyond the initiatives that are in progress, there's a lot of room for
more improvement. Here are some other ideas we'd like to see. **For many of
these ideas, the main thing they need is someone to own the design!** If you
might be interested in giving that a try, come to
[`#t-lang/roadmap-2024`](https://rust-lang.zulipchat.com/#narrow/stream/318377-t-lang.2Froadmap-2024)
to discuss, or send a private message to nikomatsakis.

| Thing | Short update |
| --- | --- |
| Deref patterns | Stalled? |
| Perfect derive | Did fundamental work on how to model, need to open RFC for coinductive trait matching |
| Autoref, operators, and clones | :zzz: |
| Generators | :zzz: |
| Async drop, async closures | :zzz: |
| Expanding dyn safe | Impl exploration as part of `dyn*` |

- **More precise analyses, less rigamarole:**
- [Deref patterns](https://github.com/rust-lang/lang-team/issues/88): Permit matching types with patterns they can dereference to, such as matching a `String` with a `"str"`.
- Perfect derive: determine the precise conditions for generic type parameters based on the types of a struct fields. For instance, `#[derive(Clone)] struct MyStruct(Rc<T>)` would not require `T: Clone`, because `Rc<T>` can be cloned without it.
- Autoref, operators, and clones: Generic methods that operate on references sometimes necessitate types like `&u32`; since `u32` is `Copy`, we could automatically make it a reference. We've historically had some hesitance to add more reference-producing operations, because it can lead to types the user doesn't expect (such as `&&&str`). We have some ideas to simplify those cases and avoid unnecessary double-references.
- **Express yourself more easily:**
- [Generators](https://github.com/rust-lang/lang-team/issues/137), allowing
users to write iterators (async and otherwise) using custom syntax.
- **Improve async support:**
- After adding async fn in traits, we intend to add support for async drop, async closures, and potentially other features.
- **Make `dyn Trait` more usable:**
- Make more patterns "object safe" and thus usable in `dyn Trait` objects, including passing `self` by value and handling `impl Trait` in argument position ([see this post for more information](https://smallcultfollowing.com/babysteps/blog/2022/01/07/dyn-async-traits-part-7/)).

## Help users help each other

| Thing | Short update |
| --- | --- |
| RFC 3240 (edition-based method disambiguation) | RFC still open, no progress |
| const generics | much progress, check with lcnr / oli-obk |
| constant evaluation | fundamental cleanup due to keyword generics, const expressions are being stabilized |
| global capabilities | no progress |
| scoped capabilities | no progress |
| negative impls | impl in nightly |
| portability initiative | active discussion |

- **Feature lifecycle:**
- RFC 3240 proposes [edition-based method disambiguation](https://github.com/rust-lang/rfcs/pull/3240), to support moving extension methods from external crates into the standard library.
- **Richer abstractions:**
- There are numerous core extensions to Rust's type system that permit richer traits to be developed. Often the lack of these features prohibits people from writing general purpose libraries because they can't get sufficient reuse:
- [Async fn in traits](https://rust-lang.github.io/async-fundamentals-initiative/)
- [Const generics](https://github.com/rust-lang/lang-team/issues/51) and [constant evaluation](https://github.com/rust-lang/lang-team/issues/22)
- [Type alias impl Trait](https://rust-lang.github.io/impl-trait-initiative/explainer/tait.html)
- [Generic associated types](https://rust-lang.github.io/generic-associated-types-initiative/)
- **Custom developer experience:**
- We are not currently doing any coordinated initiatives here, though there
are ongoing efforts that help lay groundwork for this.
- **Interoperability:**
- Support "global capabilities" like allocators or async runtimes, perhaps via an approach like [RFC 2492](https://github.com/rust-lang/rfcs/pull/2492), and perhaps extending to something like [scoped contexts and capabilities](https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/).
- [Negative impls in coherence](https://rust-lang.github.io/negative-impls-initiative/) allows for more flexibility in the coherence check by permitting crates to explicitly declare that a given type will never implement a given trait.
- The async working group's [portability initiative](https://www.ncameron.org/blog/portable-and-interoperable-async-rust/) (which builds on the work to support [async fn in traits](https://rust-lang.github.io/async-fundamentals-initiative/)) will help the async ecosystem to grow by enabling more interoperability.

### Looking forward

Looking beyond the initiatives that are in progress, there's a lot of room for more improvement. Here are some other ideas we'd like to see. **For many of these ideas, the main thing they need is someone to own the design!** If you might be interested in giving that a try, come to [`#t-lang/roadmap-2024`](https://rust-lang.zulipchat.com/#narrow/stream/318377-t-lang.2Froadmap-2024) to discuss, or send a private message to Josh Triplett.

| Thing | Short update |
| --- | --- |
| release trains | no progress |
| allow implementing fn traits | no progress |
| variadics | no progress |
| custom lints | no progress |
| customize diagnostics | no progress
| portability design | discussion |
| coherence rules | discussion |
| perf benchmarks | discussion |
| `extern "safe"` | active initiative, now called `"interop"` |

- **Feature lifecycle**:
- All ecosystem crates can have "release trains", with the equivalent of "nightly features" that require a stability opt-ins. Top-level crates retain control over whether any of their dependencies may use nightly features.
- **Richer abstractions**:
- Allow libraries to implement the `Fn` traits to define callable objects.
- Variadic tuples and variadic generics would address a common pain point of "implement this trait for tuples of any arity".
- **Custom developer experience**:
- Allow libraries to provide custom lints for their users.
- Allow libraries to control or customize Rust diagnostics, especially for trait resolution failures.
- **Interoperability**:
- Revive the stalled [portability lint](https://github.com/rust-lang/rfcs/pull/1868) or pursue an alternative design (a recent suggestion is that the "platform" might be a global service, similar to [RFC 2492](https://github.com/rust-lang/rfcs/pull/2492), permitting one to use where clauses to designate portable code)
- The coherence rules make it hard to implement interoperability traits; we should find a way to lift this restriction, while preserving coherence's key benefits.
- Adopt a standard way to write performance benchmarks (perhaps simply adopt `criterion` officially).
- Better support for dynamic linking, with richer and safer types than the C ABI. For instance, implement an `extern "safe"` providing a subset of Rust's rich types.

## Help the Rust project scale

| Thing | Short update |
| --- | --- |
| initiative project board | mildly defunct, and also initiatives themselves need revamping |
| backlog bonanza | completed, but need to do follow-up recruitment |
| feature pipeline | haven't systematically completed it, but have made progress |
| types team | launched! |
| opsem team (not listed) | FCP! |
| consensus decision process | time-delay has been implemented, but still more work to be done |

- **See the status at a glance:**
- The [initiative project board](https://github.com/orgs/rust-lang/projects/16/) tracks all the currently active initiatives that we are focusing on. For each one, it shows their [current stage](https://lang-team.rust-lang.org/initiatives/process/stages.html) along with their [owners](https://lang-team.rust-lang.org/initiatives/process/roles/owner.html) and [lang-team liaisons](https://lang-team.rust-lang.org/initiatives/process/roles/liaison.html).
- During the [backlog bonanza](https://lang-team.rust-lang.org/meetings/backlog-bonanza.html) meetings, we are going through each older tracking issue and identifying what kinds of work is needed to move it forward (needs a summary, needs design work, etc).
- We're taking the time to stabilize features that people are using, and remove incomplete features as well as features people are not using, with the eventual goal of treating everything open as "in-flight" rather than "unknown". We will also reduce the total number of in-flight features.
- **Clear owners and clear communication:**
- The [initiative system](https://lang-team.rust-lang.org/initiatives.html) assigns each task an owner, who drives the design, as well as a lang-team liaison, who helps ensure alignment with the team. More work is needed to get this system up and running smoothly.
- We are launching a [formality team](https://hackmd.io/@nikomatsakis/rJ3h_-kJc) that will take ownership of ensuring Rust's type soundness and diving into the details. This will help to grow the set of people with expertise in that area while also allowing the main lang team to consult as needed.
- **Efficient, open processes with tooling support:**
- We have designed a new [consensus decision process](https://lang-team.rust-lang.org/decision_process.html) that is designed to overcome some of the shortcomings we've seen with rfcbot; it needs to be implemented. This will help us make easily reversible decisions easier, enable more experimentation, make it smoother to raise and resolve concerns, and keep track of potential issues from proposal through to stabilization.

### Looking forward

| Thing | Short update |
| --- | --- |
| integrate older tracking issues into initiatives | obsolete-ish |
| improve visualization | no progress |
| other teams | formed opsem |
| rustbot system | no progress |
| automate proposal -> tracked initiative | obsolete |

Looking beyond the initiatives that are in progress, there's a lot of room for more improvement. Here are some other ideas we'd like to see. If you might be interested in giving that a try, come to [`#t-lang/roadmap-2024`](https://rust-lang.zulipchat.com/#narrow/stream/318377-t-lang.2Froadmap-2024) to discuss, or send a private message to Josh Triplett and nikomatsakis.

- **See the status at a glance:**
- Find ways to integrate the older tracking issues with active initiatives; reduce the manual updates required to keep the project board in sync.
- Improve the visualization of projects and blockers to something more compelling and easier to follow.
- **Clear owners and clear communication:**
- Beyond the type system, there are other areas where forming specialized teams could be useful.
- **Efficient, open processes with tooling support:**
- Generally improve rustbot to make meetings more efficient.
- Improve and automate the process of going from initiative proposal to tracked initiative.

## process tweaks

* RFC merging and managing that
* RFC unresolved questions (or similar) turning into checklists on the tracking issue
* clearer docs on how we track progress on initiatives (with a lower-case `i`)
* identifying how long something has been nominated
* including some inline information into the hackmd
* rustbot decision making protocol is "awkward"

## things not included

* keyword generics
* a-mir-formality and its integration into processes?

## Questions raised during the meeting

### How do I ask a question?

nikomatsakis: Like this!

### custom diagnostics

simulacrum: there's been some progress?

nikomatsakis: I rounded down, but it

joshtriplett: There's been an RFC for the diagnostic attribute namespace, and that RFC add'ly introduces `on_unimplemented`, intended to be a path to stabilization for the current rustc feature.

nikomatsakis: In the list of foundation grantees and I saw `#[diagnostic::]`, maybe there is something happening there, I think Esteban said they were working with them.

nikomatsakis: Seems like there's been slight progress, maybe we should see if we can give it more momentum.

scottmcm: reminds me of ownership/unblocking, a bunch of that was "how can we let compiler/diagnostics people do stuff that's really good without necessarily making it a strong stability promise, so that things can just sort of happen and get better?" a bunch of nuance there on how much of that is good.

### expanding dyn safe

pnkfelix: what is "dyn safe"?

*Clarified to be the concept formerly known as object safety*

scottmcm: Wasn't there something about tweaking `dyn Foo: Foo` not always holding?

nikomatsakis: in fact that constraint was dropped some time back, but still further loosening

### Can we add default fields or something?

scottmcm: I still want Esteban's sketch in <https://internals.rust-lang.org/t/pre-pre-rfc-syntactic-sugar-for-default-default/13234/75?u=scottmcm>.

nikomatsakis: building on Scott's previous point, I still wonder about having a small set of "delighters", things like let-else that don't fundamentally change computing in Rust but just make it more, well, delightful.

scottmcm: I was specifically reminded of this this morning in a conversation about mapping C types where they expect to be able to add zero-init fields as a non-breaking change in certain situations.

nikomatsakis: I think this comes to doing "global product management", i.e., looking across the palette of work and making sure we're balancing it.

tmandry: custom diagnostics could really impact this too

nikomatsakis: Josh, didn't you talk to someone about expanding procedural macros?

joshtriplett: no idea

pnkfelix: in project grantees...search for "shepherd's oasis"

joshtriplett: Ah, yes.

nikomatsakis: seems related in that it gives ability for crate authors to deliver the delighters instead of us

### on clear ownership

scottmcm: I like to see it, and I think there's a bunch more places. "Who can approve lints?" came up recently on zulip, for example <https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/not_unsafe_ptr_arg_deref.20uplift/near/319639818>

nikomatsakis: types + opsem team making this better?

scottmcm: probably good. Have the page that makes it clear that not everyone wants to be experts in Gentzen inference rules ...

### Things that were missing?

nikomatsakis: What is missing :)

tmandry: some of the stuff proliferating out of async fn in trait, like return type notation... kind of putting that under the umbrella.

joshtriplett: Ah, perf benchmarks was specifically about a standard way to write them for crates, not a perf suite for us -- never mind.

nikomatsakis: specific thing I think we could do organizationally -- we need process for making decisions around what kinds of optimizations we can do.

pnkfelix: problem is how you're going to specify that -- can sketch out code and say "always valid for compiler to turn this into that" -- in the specific case you're talking about, e.g., with an upvar, you can make an example that shows the overhead. I don't know. I guess there's a question of how you want to specify the optimization characterics. End up getting mired.

nikomatsakis: formulating the question is hard

pnkfelix: makes sense to make goalposts: these are cases we should definitely optimize. But goalpost is still the same. Maybe the rules that lead you there changes, but the result is the same.

nikomatsakis: I think I'm saying, we should be delivering "ability to optimize code".

pnkfelix: I think the person who will own that should be the opsem team. But I don't know if the lang team should be the ones driving this decision. But we can say that I think we should be investing effort in the goal.

tmandry: makes me think of pointer provenance

nikomatsakis: I am thinking that it's part of the "maturity" theme. I'm not sure how exactly lang team should say it but goalposts feels maybe right -- probably other teams are making those fine-grained decisions, bujt if we are owning the "end-user experience" of writing Rust, so being able to say "this kind of code should be what you expect to write" does feel in-scope.

tmandry: C++ interop -- where does that slot in? There's some stuff happening there?

nikomatsakis: "specification" -- and a-mir-formality -- feel like "helping rust project scale".

### What could we "drop" from roadmap?

... going through the things marked as no-progress ...

nikomatsakis: the one that seems *closest* to being shipped is "global capabilities"

joshtriplett: yes, or global where-clauses? facade crates?

joshtriplett: separate from "portability"

nikomatsakis: I am not sure how broadly discussed that idea of moving portability into trait system has been discussed, but feels transformative, not a huge stretch from a technical perspective. That might be one to highlight if we were going to pick one to "call out" for

joshtriplett: I think Mara was interested in it, but she's still focused on the spec work and the interop.

nikomatsakis: it feels like another thing that would be easier with an improved trait solver.

tmandry: for structured concurrency, do we need language extensions?

nikomatsakis: keyword generics, scoped capabilities...

tmandry: ...the fact that you can't soundly implement

scottmcm: makes me think we should really call out new trait solver as a thing that would enable new projects. Have all these things we want to do...

nikomatskais: types team should publish its roadmap.

nikomatsakis: if we hit 2024 and what we have is AFIT, TAIT, GATs, that's a hell of a release

### 2024 edition

Josh: what requires 2024 edition changes?

scottmcm: good point, following our rule, we better start now...

joshtriplett: several items that, if they were going to be done, would need an edition, but they're all marked as "no progress"...

nikomatsakis: which ones?

joshtriplett: async-drop, auto-ref operators, clones, possibly something involving deref patterns, possibly some of the perfect derive work

scottmcm: ...the FRU change...

joshtriplett: (a) yes, absolutely and (b) would somebody be excited about reviving the work that was already done there? I have someone who has an RFC draft and finding myself without the bandwidth to keep working with them. Wondering if somebody would wan to tag in.

scottmcm: I could. I might be a good &lt;frenchily pronounced>liasón&lt;/frenchily pronounced>

tmandry: pin-projection? (mic drop)

scottmcm: field projection question mark?

joshtriplett: there was a general field projection RFC that I personally thought was really promising

scottmcm: I assume not happening, but `=` in struct initializers? ;)