You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: posts/2025-03-03-Project-Goals-Feb-Update.md
+6-6Lines changed: 6 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -16,19 +16,19 @@ This is the first Project Goals update for the new 2025h1 period. For the first
16
16
</div>
17
17
<!-- markdown separator -->
18
18
19
-
**Why this goal?** This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the `dynosaur` crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 [our plan](https://rust-lang.github.io/rust-project-goals/2025h1/async.html) is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the [`async-trait` crate](https://crates.io/crates/async-trait); (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of `Pin`, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.
19
+
**Why this goal?** This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the `dynosaur` crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 [our plan](https://rust-lang.github.io/rust-project-goals/2025h1/async.html) is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the [`async-trait` crate](https://crates.io/crates/async-trait); (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of `Pin`, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.
20
20
21
21
**What has happened?** The biggest news is that Rust 1.85 is stable and includes two major features that impact Async Rust. The first is [async closures](https://blog.rust-lang.org/inside-rust/2024/08/09/async-closures-call-for-testing.html), which has been on many people's wish lists for a long time and was expertly moved forward by @compiler-errors over the last year.
22
22
23
-
The second feature included in 1.85 is the new [lifetime capture rules](https://doc.rust-lang.org/edition-guide/rust-2024/rpit-lifetime-capture.html) as part of Rust 2024 edition. This should substantially improve the experience of using async Rust anytime a user writes `-> impl Future`, as it removes the need for `+ '_` or similar bounds in most cases. It will also lead to an easier to understand language, since those bounds only worked by exploiting the more subtle rules of `impl Trait` in a way that runs contrary to their actual semantic role in the language. In the 2024 Edition, the subtle rule is gone and we capture all input lifetimes by default, with the ability to use `+ use<>` syntax to opt out. See [this blog post](https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html) for more.
23
+
The second feature included in 1.85 is the new [lifetime capture rules](https://doc.rust-lang.org/edition-guide/rust-2024/rpit-lifetime-capture.html) as part of Rust 2024 edition. This should substantially improve the experience of using async Rust anytime a user writes `-> impl Future`, as it removes the need for `+ '_` or similar bounds in most cases. It will also lead to an easier to understand language, since those bounds only worked by exploiting the more subtle rules of `impl Trait` in a way that runs contrary to their actual semantic role in the language. In the 2024 Edition, the subtle rule is gone and we capture all input lifetimes by default, with the ability to use `+ use<>` syntax to opt out. See [this blog post](https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html) for more.
24
24
25
-
**Generators.** The lang team also held a design meeting to review the design for generators, with the outcome of the last one being that we will implement a `std::iter::iter!` macro (exact path TBD) in the compiler, as a lang team experiment that allows the use of the `yield` syntax. We decided to go in this direction because we want to reserve `gen` for self-borrowing and perhaps lending generators, and aren't yet decided on which subset of features to expose under that syntax. This decision interacts with ongoing compiler development that isn't ready yet to enable experimentation with lending.
25
+
**Generators.** The lang team also held a design meeting to review the design for generators, with the outcome of the last one being that we will implement a `std::iter::iter!` macro (exact path TBD) in the compiler, as a lang team experiment that allows the use of the `yield` syntax. We decided to go in this direction because we want to reserve `gen` for self-borrowing and perhaps lending generators, and aren't yet decided on which subset of features to expose under that syntax. This decision interacts with ongoing compiler development that isn't ready yet to enable experimentation with lending.
26
26
27
-
Our hope is that in the meantime, by shipping `iter!` we will give people the chance to start using generators in their own code and better understand which limitations people hit in practice.
27
+
Our hope is that in the meantime, by shipping `iter!` we will give people the chance to start using generators in their own code and better understand which limitations people hit in practice.
28
28
29
29
As you may have noticed, I'm not talking about async generators here. Those are the ultimate goal for the async initiative, but we felt the first step should be clarifying the state of synchronous generators so we can build on that when talking about async ones.
30
30
31
-
**Dynosaur.**[dynosaur v0.1.3](https://github.com/spastorino/dynosaur/releases/tag/0.1.3) was released, with another release in the works. We think we are approaching a 1.0 release real soon now (tm). At this point you should be able to try it on your crate to enable dyn dispatch for traits with `async fn` and other `-> impl Trait` methods. If you need to use it together with `#[trait_variant]`, you may need to wait until the next release when [#55](https://github.com/spastorino/dynosaur/issues/55) is fixed.
31
+
**Dynosaur.**[dynosaur v0.1.3](https://github.com/spastorino/dynosaur/releases/tag/0.1.3) was released, with another release in the works. We think we are approaching a 1.0 release real soon now (tm). At this point you should be able to try it on your crate to enable dyn dispatch for traits with `async fn` and other `-> impl Trait` methods. If you need to use it together with `#[trait_variant]`, you may need to wait until the next release when [#55](https://github.com/spastorino/dynosaur/issues/55) is fixed.
32
32
33
33
<!-- markdown separator -->
34
34
@@ -155,7 +155,7 @@ Next up:
155
155
</div>
156
156
<!-- markdown separator -->
157
157
158
-
**Why this goal?** This goal continues our work from 2024H2 in supporting the [experimental support for Rust development in the Linux kernel][RFL.com]. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement [RFC #3716] which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.md); (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).
158
+
**Why this goal?** This goal continues our work from 2024H2 in supporting the [experimental support for Rust development in the Linux kernel][RFL.com]. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement [RFC #3716] which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing [`build-std`](https://doc.rust-lang.org/cargo/reference/unstable.html#build-std) by [creating a stable way to rebuild core with specific compiler options](./build-std.md); (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).
0 commit comments