rename async goal URL

Author: nikomatsakis

book.toml

@@ -12,3 +12,6 @@ edit-url-template = "https://github.com/rust-lang/rust-project-goals/edit/main/{
 [output.html.fold]
 enable = true
 level = 1
+
+[output.html.redirect]
+"/2024h2/async_fn_everywhere.html" = "/2024h2/async.html"

src/2024h2/candidates.md

@@ -76,7 +76,7 @@ In many cases the work being described will definitely happen, but it is not cle
 
 [EI]: ./ergonomics-initiative.md
 [FIB]: ./faster-iterative-builds.md
-[AFE]: ./async_fn_everywhere.md
+[AFE]: ./async.md
 [LK]: ./rfl_stable.md
 [LKH]: ./rfl_stable.md#ownership-and-other-resources
 [SCS]: ./Seamless-C-Support.md

src/2024h2/ergonomics-initiative.md

@@ -10,7 +10,7 @@
 
 ## Motivation
 
-For 2024H2, we propose to continue with the [ergonomics initiative](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html), targeting several of the biggest friction points in everyday Rust development. These issues affect all Rust users, but the impact and severity varies dramatically. Many experienced users have learned the workarounds and consider them papercuts, but for newer users, or in domains traditionally considered "high-level" (e.g., app/game/web development, data science, scientific computing) these kinds of issues can make Rust a non-starter. In those domains, Rust has picked up momentum as a language for building underlying frameworks and libraries thanks to its lower-level nature. However, thanks in large part to these kind of smaller, papercut issues, it is not a great choice for **consumption** of these libraries - many projects instead choose to expose bindings for languages like Python and JavaScript. The motivation of this project goal is to make Rust a better choice for higher level programming subfields by identifying and remedying language papercuts with minimally invasive language changes. In fact, these same issues arise in other Rust domains: for example, Rust is a graet choice for network services where performance is a top consideration, but perhaps not a good choice for "everyday" request-reply services, thanks in no small part to papercuts and small-time friction (as well as other gaps like the needing more libraries, which are being addressed in the [async goal](./async_fn_everywhere.md)).
+For 2024H2, we propose to continue with the [ergonomics initiative](https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html), targeting several of the biggest friction points in everyday Rust development. These issues affect all Rust users, but the impact and severity varies dramatically. Many experienced users have learned the workarounds and consider them papercuts, but for newer users, or in domains traditionally considered "high-level" (e.g., app/game/web development, data science, scientific computing) these kinds of issues can make Rust a non-starter. In those domains, Rust has picked up momentum as a language for building underlying frameworks and libraries thanks to its lower-level nature. However, thanks in large part to these kind of smaller, papercut issues, it is not a great choice for **consumption** of these libraries - many projects instead choose to expose bindings for languages like Python and JavaScript. The motivation of this project goal is to make Rust a better choice for higher level programming subfields by identifying and remedying language papercuts with minimally invasive language changes. In fact, these same issues arise in other Rust domains: for example, Rust is a graet choice for network services where performance is a top consideration, but perhaps not a good choice for "everyday" request-reply services, thanks in no small part to papercuts and small-time friction (as well as other gaps like the needing more libraries, which are being addressed in the [async goal](./async.md)).
 
 ### The status quo
 

src/2024h2/slate.md

@@ -56,12 +56,12 @@ Flagship goals are the most impactful, most ambitious goals that we will attempt
     * along with an [assortment of other possible changes](TODO)
     * never type fallback ([#123748](https://github.com/rust-lang/rust/issues/123748))
     * and a [number of other potential changes](https://github.com/rust-lang/rust/issues?q=label%3AC-tracking-issue+label%3AA-edition-2024+label%3AS-tracking-ready-to-stabilize%2CS-tracking-needs-documentation+-label%3AS-tracking-impl-incomplete%2CS-tracking-design-concerns) that may be included if they make enough progress
-* [**Bringing the Async Rust experience closer to parity with sync Rust**](./async_fn_everywhere.md) [via](./async_fn_everywhere.md#the-next-few-steps):
+* [**Bringing the Async Rust experience closer to parity with sync Rust**](./async.md) [via](./async.md#the-next-few-steps):
     * stabilizing async closures, thus enabling richer, combinator APIs like sync Rust's [`Iterator`](https://doc.rust-lang.org/std/iter/trait.Iterator.html);
-    * [resolving the "send bound problem"](./async_fn_everywhere.md#resolve-the-send-bound-problem), thus enabling foundational, generic traits like Tower's [`Service`]() trait;
-    * [stabilizing a trait in libstd for async iteration](./async_fn_everywhere.md#stabilize-trait-for-async-iteration), thus enabling the ecosystem to build atop a stable foundation;
-    * [authoring a draft RFC for async vision](./async_fn_everywhere.md#author-draft-rfc-for-async-vision), thus aligning the project around a coherent vision;
-    * [completing the async drop experiments](./async_fn_everywhere.md#complete-async-drop-experiments) proposed in [MCP 727][], laying the groundwork for resolving the the next most
+    * [resolving the "send bound problem"](./async.md#resolve-the-send-bound-problem), thus enabling foundational, generic traits like Tower's [`Service`]() trait;
+    * [stabilizing a trait in libstd for async iteration](./async.md#stabilize-trait-for-async-iteration), thus enabling the ecosystem to build atop a stable foundation;
+    * [authoring a draft RFC for async vision](./async.md#author-draft-rfc-for-async-vision), thus aligning the project around a coherent vision;
+    * [completing the async drop experiments](./async.md#complete-async-drop-experiments) proposed in [MCP 727][], laying the groundwork for resolving the the next most
 * [**Resolving the biggest blockers to Linux building on stable Rust**](./rfl_stable.md) [via](./rfl_stable.md#the-next-few-steps):
     * [stabilizing support for arbitrary `self` types and unsizeable smart pointers](./rfl_stable.md#stable-support-for-rfls-customized-arc-type), thus permitting ergonomic support for [in-place linked lists](https://rust-for-linux.com/arc-in-the-linux-kernel) on stable;
     * [stabilizing features for labeled goto in inline assembler and extended `offset_of!` support](./rfl_stable.md#labeled-goto-in-inline-assembler-and-extended-offset_of-support), needed for various bts of low-level coding;

src/SUMMARY.md

@@ -5,7 +5,7 @@
     - [The slate](./2024h2/slate.md)
     - [All candidates](./2024h2/candidates.md)
         - [Template](./TEMPLATE.md)
-        - [Async closures and send bounds](./2024h2/async_fn_everywhere.md)
+        - [Async Rust](./2024h2/async.md)
         - [Linux kernel builds on stable Rust](./2024h2/rfl_stable.md)
         - [Ergonomics initiative](./2024h2/ergonomics-initiative.md)
         - [Faster iterative builds](./2024h2/faster-iterative-builds.md)