It should come as no surprise that life lately has been dominated by the upcoming Rust 1.0 release. But now that the beta release is out the door, I’ve started to give some thought to what we ought to do next. Obviously, there is no shortage of good ideas out there for how to grow the language. Just as obviously, we need to be careful about what we implement and when we implement it.

This post represents an initial stab at assigning priorities to the upcoming tasks. It is based on my attempts to survey the many proposals for extending Rust, as well as talking things over with users of Rust (particularly production users). I’d really love to hear more feedback (here on the discuss thread, ideally). I also expect we’ll be constantly adjusting priorities as we go. I plan to draw up a public Google doc that we keep up to date tracking this sort of high-level priorities information; haven’t done it yet.

How to decide what to prioritize

So how should we decide what to work on now versus later? I think the two most important criteria are time-sensitivity and impact:

Time-sensitivity. Some changes are just going to get harder and harder to do over time. Particularly around unsafe code, de facto dependencies and assumptions can crop up and make it hard to introduce changes. Some examples where this might be relevant are dynamic drop, allocators, and tracing support. Impact. Some features have the potential to affect a large number of problems, or else a large number of users. An example of the former is trait specialization, which can potentially address a number of existing problems and needs. An example of the latter is improved compilation performance, which affects every Rust user.

Top priority

These things seem like they are the most urgent to me. Many of them already have people working on them. Those that don’t will be top priority as people-power becomes available. I’ve put down names of owner(s) for each item: these are the people that are currently planning on driving the design and impl work forward. If you’d like to be more involved in one of these items, they would be good people to contact!

Library APIs. We’ve stabilized a large portion of std, but there are many important things that didn’t make it. Issue 24028 has a more complete list, but I want to highlight a few things in particular as needing attention:

Filesystem APIs. We plan to flesh these out so that we can get the cargo implementation running on stable Rust. Memory allocation APIs. We know that being able to allocate a bag-of-bytes would be very useful for a number of projects. The main reason we haven’t pursued this is because of concern about possible interactions with GC/tracing support (see below). But we plan to introduce some kind of stable allocator API very soon.

In addition, we would like to put some energy into developing useful libraries that are not (necessarily) part of the standard library but which fill important gaps. For example, I know @aturon is chomping at the bit to build some parallel programming abstractions. Owner: aturon, acrichto.

Better Windows and ARM support. Both Windows and ARM are huge, important markets where Rust support still needs work. Improving our support in these areas will help make Rust attractive for a larger number of people. With respect to Windows, the overall goal is to remove our dependence on the MinGW toolchain but this will take a number of steps to achieve (more discussion here is needed). With respect to ARM, the primary goal is support for the ARM64 architecture. Owner: brson.

Faster compilation. We’ve put a lot of effort into building up the feature set and relatively little into optimizing. There’s a lot of low-hanging fruit here, but also an opportunity to rearchitect parts of the compiler and gain huge wins. I’d like to see progress towards parallel and incremental compilation, for example, both in the backend (LLVM side) and the front end (type checker, etc). I’d also really like to take some time to overhaul the trait matching and type inference scheme; it needs some work to better handle associated types in particular. Owner: nrc, nmatsakis.

Better support for distributing Rust libraries and programs. There are a number of things we can do to make distributing Rust executables and libraries easier. cargo install is an oft-requested feature that will require some careful design. Another piece here is being able to distribute binaries with minimal external dependencies; being able to link to MUSL might be a big help here. Owner: acrichto.

Better tool support. While Rust now has fairly decent debuginfo, it can always be better. And it’d be great to have integration with other tools like fuzzers, line coverage, profilers, etc. Having a healthy ecosystem with quality tools – and in particular, being able to leverage C tools where it makes sense – seems crucial to widespread adoption. Owner: nrc, brson.

Dynamic drop. We need to remove the zeroing flags and implement the dynamic drop semantics we agreed to in RFC 320. It’s important to do this sooner rather than later to avoid de facto dependencies arising from unsafe code (Felix made a mitigating change aimed at encouraging people to write forwards compatible code, but that was only a stopgap measure). Furthermore, this change should improve compilation and execute performance across the board. Owner: pnkfelix.

Allocators/Tracing. We need to offer more control over memory allocation. This touches on a number of areas. For example, it can be useful to use different kinds of allocators in different parts of your program (in the direction of RFC 244). It would also be good to make it easier to control the global allocator. We need a stable routine like malloc/free. And, crucially, we’d like all of that while also having the ability to trace live values on the stack, so that we can integrate with garbage collectors – this is particularly important when linking to dynamic langauges or other GC’d runtimes, but might also be useful in plain Rust, particularly for some kinds of non-blocking data structures. (LLVM’s new and improved support for tracing offers exciting opportunities here.) This is a very time-sensitive topic: if we don’t act soon, the growth of unsafe libraries may severely limit our options here. Owner: pnkfelix.

Specialization. Specialization allows there to be multiple implementations of a given trait for a given set of types. Over the past few months or so, I’ve seen numerous examples of situations where specialization could help to address coherence limitations or to improve performance. I think it’s important to get the ball rolling on a design here. Owner: aturon, nmatsakis.

Virtual structs. For certain use cases, there is an urgent need to generalize the current setup of enum/structs and traits. This led to the so-called “virtual struct” proposal in the past. In the past, we focused on the efficiency questions, but I think there is also a need to make some patterns more convenient to write. In any case, previous experience suggests it’s going to be tricky to get the design right here, so I expect we’ll wind up spending some amount of time iterating in the RFC process. I’ve been doing a lot of thinking on this lately and I hope to put out some blog posts soon working through some aspects of the problem and the design space. Owner: aturon, nrc, nmatsakis.

Possibly high priority

There are some tasks whose priority feels harder to calculate. They are both tasks that will take a fair amount of effort, but it might be worth it!

Borrow checker improvements. I would very much like to start working on a concerete design to solve #6268 and #6393. Prioritizing this feels a bit hard though. On the one hand, both of these problems are (usually) relatively easy to work-around, but they affect a large number of new users, and removing them might go a long way towards improving the initial “Rust experience”. Owner: nmatsakis.

Improved macros and syntax extensions. Rust 1.0 includes the existing macro_rules system, but it has a lot of known problems. Perhaps the biggest is the lack of “privacy” or "unsafety" hygiene (meaning that it’s not possible to define macros that have privileged access over normal code). This prevents macros from being used to define abstraction barriers. There is also no integration with the normal import/export mechanisms of the language. Going further, Rust has always intended to have the ability to link in “syntax extensions”, which are macros whose implementation is written in Rust rather than using a declarative form. There is a prototype now but the API exposes far too many of the compiler internals to be considered stable. We need to better identify the use-cases we’d like to support and what kind of stable API we can offer. This is also somewhat tricky to characterize: any changes here will be backwards compatible, and many of the same effects can be achieved with pre-processing for the time being. On the other hand, several popular libraries (e.g., serde, sql, regex) have demonstrated the power and appeal of syntax extensions. Owner: nrc.

Mid-priority

There are a grab-bag of smaller RFCs and changes I’d like to see forward motion on. These issues seem to be relatively self-contained: it will still take some time to find a design everyone is happy with, but it doesn’t look like the design here will have large interactions with the rest of the language.

The try and ? operator for improved error-handling. See rust-lang/rfcs#243.

See rust-lang/rfcs#243. Overloadable += operators. See rust-lang/rfcs#953.

See rust-lang/rfcs#953. Overflow ergonomics. It’d be nice to be able to write overflowing operations more concisely, when you want them. Probably. See this internals thread.

It’d be nice to be able to write overflowing operations more concisely, when you want them. Probably. See this internals thread. Rvalue promotion. The idea here is to allow constants like &[1, 2, 3] to have static lifetime. Currently, they are limited to a lifetime that would permit them to be stored on the stack. A lot of the work on identifying which cases are legal has been done, but it needs to be written up and thought through a bit more. See rust-lang/rfcs#1056.

The idea here is to allow constants like to have static lifetime. Currently, they are limited to a lifetime that would permit them to be stored on the stack. A lot of the work on identifying which cases are legal has been done, but it needs to be written up and thought through a bit more. See rust-lang/rfcs#1056. Smart pointer enhancements. In particular, we need support for DerefMove , IndexMove , IndexSet , and NonZero . Unlike the other cases, the design here actually is subtle, but we should be able to base the work on the existing traits in a fairly straightforward way. See rust-lang/rfcs#997.

Longer term

This final group includes changes that I see as being somewhat longer term. These are mostly larger, cross-cutting changes that will deeply affect the language and libraries. I think it’s great to keep thinking and working on these larger items – particularly on their design – but they are less likely to be integrated into Rust proper until other large features have been completed. This is both because it takes a lot of work to finalize the design and because the design will benefit from more time and experience. It seems likely that with an influx of new users, we will find new use cases (or new ways to solve the problem without changing the language).