> Now, there are issue threads like this, in which 25 smart, well meaning people spent 2 years and over 200 comments trying to figure out how to improve Mutex. And as far as I can tell, in the end they more or less gave up.<p>The author of the linked comment did extensive analysis on the synchronization primitives in various languages, then rewrote Rust's synchronization primitives like Mutex and RwLock on every major OS to use the underlying operating system primitives directly (like futex on Linux), making them faster and smaller and all-around better, and in the process, literally <i>wrote a book</i> on parallel programming in Rust (which is useful for non-Rust parallel programming as well): <a href="https://www.oreilly.com/library/view/rust-atomics-and/9781098119430/" rel="nofollow">https://www.oreilly.com/library/view/rust-atomics-and/978109...</a><p>> Features like Coroutines. This RFC is 7 years old now.<p>We haven't been idling around for 7 years (either on that feature or in general). We've added asynchronous functions (which whole ecosystems and frameworks have arisen around), traits that can include asynchronous functions (which required <i>extensive</i> work), and many other features that are both useful in their own right and needed to get to more complex things like generators. Some of these features are also critical for being able to standardize things like `AsyncWrite` and `AsyncRead`. And we now have an implementation of generators available in nightly.<p>(There's some debate about whether we <i>want</i> the complexity of fully general coroutines, or if we want to stop at generators.)<p>Some features have progressed slower than others; for instance, we still have a lot of discussion ongoing for how to design the AsyncIterator trait (sometimes also referred to as Stream). There have absolutely been features that stalled out. But there's a <i>lot</i> of active work going on.<p>I always find it amusing to see, simultaneously, people complaining that the language isn't moving fast enough and other people complaining that the language is moving too fast.<p>> Function traits (effects)<p>We had a <i>huge</i> design exploration of these quite recently, right before RustConf this year. There's a challenging balance here between usability (fully general effect systems are <i>complicated</i>) and power (not having to write multiple different versions of functions for combinations of async/try/etc). We're enthusiastic about shipping a solution in this area, though. I don't know if we'll end up shipping an <i>extensible</i> effect system, but I think we're very likely to ship a system that allows you to write e.g. one function accepting a closure that works for every combination of async, try, and possibly const.<p>> Compile-time Capabilities<p>Sandboxing against <i>malicious</i> crates is an out-of-scope problem. You can't do this at the language level; you need some combination of a verifier and runtime sandbox. WebAssembly components are a much more likely solution here. But there's lots of interest in having capabilities for other reasons, for things like "what allocator should I use" or "what async runtime should I use" or "can I assume the platform is 64-bit" or similar. And we do want sandboxing of things like proc macros, not because of malice but to allow accurate caching that knows everything the proc macro depends on - with a sandbox, you know (for instance) exactly what files the proc macro read, so you can avoid re-running it if those files haven't changed.<p>> Rust doesn't have syntax to mark a struct field as being in a borrowed state. And we can't express the lifetime of y.<p>> Lets just extend the borrow checker and fix that!<p>> I don't know what the ideal syntax would be, but I'm sure we can come up with something.<p>This has never been a problem of syntax. It's a <i>remarkably</i> hard problem to make the borrow checker able to handle self-referential structures. We've had a couple of iterations of the borrow checker, each of which made it capable of understanding more and more things. At this point, I <i>think</i> the experts in this area have ideas of <i>how</i> to make the borrow checker understand self-referential structures, but it's still going to take a substantial amount of effort.<p>> This syntax could also be adapted to support partial borrows<p>We've known how to do partial borrows for quite a while, and we already support partial borrows in closure captures. The main blocker for supporting partial borrows in public APIs has been how to expose that to the type system in a forwards-compatible way that supports maintaining stable semantic versioning:<p>If you have a struct with private fields, how can you say "this method and that method can borrow from the struct at the same time" without exposing details that might break if you add a new private field?<p>Right now, leading candidates include some idea of named "borrow groups", so that you can define your own subsets of your struct without exposing what private fields those correspond to, and so that you can change the fields as long as you don't change which combinations of methods can hold borrows at the same time.<p>> Comptime<p>We're actively working on this in many different ways. It's not trivial, but there are many things we can and will do better here.<p>I recently wrote two RFCs in this area, to make macro_rules more powerful so you don't need proc macros as often.<p>And we're already talking about how to go even further and do more programmatic parsing using something closer to Rust constant evaluation. That's a <i>very</i> hard problem, though, particularly if you want the same flexibility of macro_rules that lets you write a macro and use it in the same crate. (Proc macros, by contrast, require you to write a separate crate, for a variety of reasons.)<p>> impl<T: Copy> for Range<T>.<p>This is already in progress. This is tied to a backwards-incompatible change to the range types, so it can only occur over an edition. (It would be possible to do it without that, but having Range implement both Iterator and Copy leads to some easy programming mistakes.)<p>> Make if-let expressions support logical AND<p>We have an unstable feature for this already, and we're close to stabilizing it. We need to settle which one or both of two related features we want to ship, but otherwise, this is ready to go.<p><pre><code> > But if I have a pointer, rust insists that I write (*myptr).x or, worse: (*(*myptr).p).y.
</code></pre>
We've had multiple syntax proposals to improve this, including a postfix dereference operator and an operator to navigate from "pointer to struct" to "pointer to field of that struct". We don't currently have someone championing one of those proposals, but many of us are fairly enthusiastic about seeing one of them happen.<p>That said, there's also a danger of spending too much language weirdness budget here to buy more ergonomics, versus having people continue using the less ergonomic but more straightforward raw-pointer syntaxes we currently have. It's an open question whether adding more language surface area here would on balance be a win or a loss.<p>> Unfortunately, most of these changes would be incompatible with existing rust.<p>One of the wonderful things about Rust editions is that there's very little we <i>can't</i> change, if we have a sufficiently compelling design that people will want to adopt over an edition.<p>> The rust "unstable book" lists 700 different unstable features - which presumably are all implemented, but which have yet to be enabled in stable rust.<p>This is <i>absolutely</i> an issue; one of the big open projects we need to work on is going through all the existing unstable features and removing many that aren't likely to ever reach stabilization (typically either because nobody is working on them anymore or because they've been superseded).