Merge pull request #240 from tmandry/redirect-fundamentals

Move async fundamentals out of this repo

Author: nikomatsakis

src/SUMMARY.md

@@ -28,13 +28,6 @@
     - [📚 User's manual of the future](./vision/shiny_future/users_manual.md)
   - [📅 Roadmap](./vision/roadmap.md)
     - [Async fn everywhere](./vision/roadmap/async_fn.md)
-      - [Async fn fundamentals](./vision/roadmap/async_fn/async_fn_fundamentals.md)
-        - [Static async trait](./vision/roadmap/async_fn/async_fn_fundamentals/static_async_trait.md)
-        - [impl Trait in traits](./vision/roadmap/async_fn/async_fn_fundamentals/impl_trait_in_traits.md)
-        - [Dyn async trait](./vision/roadmap/async_fn/async_fn_fundamentals/dyn_async_trait.md)
-        - [Dyn trait](./vision/roadmap/async_fn/async_fn_fundamentals/dyn_trait.md)
-        - [Async drop](./vision/roadmap/async_fn/async_fn_fundamentals/async_drop.md)
-        - [Async closures](./vision/roadmap/async_fn/async_fn_fundamentals/async_closures.md)
       - [Boxable async fn](./vision/roadmap/async_fn/boxable.md)
       - [Async main and tests](./vision/roadmap/async_fn/async_main_and_tests.md)
     - [Scoped spawn and reliable cancellation](./vision/roadmap/scopes.md)

src/design_docs/async_drop.md

@@ -1 +1 @@
-# 🗑️ Async drop
+# 🗑️ Async drop

src/design_docs/async_fn_in_traits.md

@@ -1,88 +1 @@
 # 🧬 Async fn in traits
-
-* [Why async fn in traits are hard][wafth]
-
-[wafth]: http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/
-
-## General goal
-
-```rust,ignore
-trait Foo {
-    // Currently disallowed:
-    async fn bar();
-}
-```
-
-## Concerns
-
-### How to name the resulting future
-
-If you wanted to name the future that results from calling `bar` (or whatever), you can't.
-
-Also true for functions `fn bar() -> impl Trait`.
-
-### Requiring `Send` on futures
-
-[Relevant thread](https://internals.rust-lang.org/t/how-often-do-you-want-non-send-futures/10360)
-
-```rust,ignore
-async fn foo() {}
-
-// desugars to
-fn foo() -> impl Future<Output = ()> { } // resulting type is Send if it can be
-
-// alternative desugaring we chose not to adopt would require Send
-fn foo() -> impl Future + Send { }
-```
-
-If I want to constrain the future I get back from a method, it is difficult to do without a name:
-
-```rust,ignore
-trait Service {
-    async fn request(&self);
-}
-
-fn parallel_service<S: Service>()
-where
-    S::Future: Send,
-{
-    ...
-}
-```
-
-* Should this be solved at the impl trait layer
-* Or should we specialize something for async functions
-* Would be nice, if there are many, associated types, to have some shorthand
-
-## Example use case: the Service
-
-```rust,ignore
-trait Service {
-    type Future: Future<Output = Response>;
-
-    fn request(&self, ...) -> Self::Future;
-}
-
-impl Service for MyService {
-    type Future = impl Future<Output = Response>;
-
-    fn request(&self) -> Self::Future {
-        async move { .. }
-    }
-}
-```
-
-* Dependent on impl Trait, see lang-team repo
-
-## Example use case: capturing lifetimes of arguments
-
-```rust,ignore
-trait MyMethod {
-    async fn foo(&self);
-}
-```
-
-## 🤔 Frequently Asked Questions
-
-### **What do people say about this to their friends on twitter?**
-* (Explain your key points here)

src/design_docs/async_main.md

@@ -1,7 +1 @@
 # 🎇 Async main
-
-## What is it?
-
-## Motivation
-
-## Frequently Asked Questions

src/design_docs/completion_based_futures.md

@@ -1,5 +1 @@
 # ⏳ Completion-based futures
-
-[Notes on io_uring][withoutboats-blog]
-
-[withoutboats-blog]: https://boats.gitlab.io/blog/post/io-uring

src/design_docs/generator_syntax.md

@@ -1,10 +1 @@
-# ⚡  Generator syntax
-
-* It would be useful to be able to write a function to return an iterator or (in the async context) a generator
-* The basic shape might be (modulo bikeshedding) `gen fn` that contains `yield`
-* Some question marks:
-    * How general of a mechanism do we want?
-        * Just target iterators and streams, or shoot for something more general?
-* Some of the question marks that arise if you go beyond iterators and streams:
-    * Return values that are not unit
-    * Have yield return a value that is passed by the caller of `next` ("resume args")
+# ⚡ Generator syntax

src/design_docs/mutex.md

@@ -1,7 +1 @@
 # 🔒 Mutex (future-aware)
-
-[Description of various challenges with async mutexes][blog]
-
-[blog]: https://github.com/Diggsey/posts/tree/master/async-mutexes
-
-

src/design_docs/stream.md

@@ -1,48 +1 @@
 # ☔ Stream trait
-
-* [Current definition](https://docs.rs/futures/0.3/futures/stream/trait.Stream.html)
-
-## Trait definition
-
-```rust,ignore
-pub trait Stream {
-    type Item;
-
-    fn poll_next(
-        self: Pin<&mut Self>,
-        cx: &mut Context<'_>,
-    ) -> Poll<Option<Self::Item>>;
-
-    #[inline]
-    fn size_hint(&self) -> (usize, Option<usize>) {
-        (0, None)
-    }
-}
-```
-
-## Concerns
-
-### Poll-based design
-
-* You have to think about Pin if you implement this trait.
-* Combinators can be more difficult.
-* One solution: [generator syntax](./generator_syntax.md).
-
-### Attached streams are commonly desired
-
-Sometimes streams need to reuse internal storage ([Discussion]).
-
-[Discussion]: http://smallcultfollowing.com/babysteps/blog/2019/12/10/async-interview-2-cramertj-part-2/#the-need-for-streaming-streams-and-iterators
-
-### Combinators
-
-* Currently the combinations are stored in the [`StreamExt`] module.
-* In some cases, this is because of the lack of async closures support.
-    * Also serves as a "semver barrier".
-    * Also no-std compatibility.
-* One question: what combinators (if any) to include when stabilizing?
-    * e.g., [`poll_next_unpin`] can make working with pin easier, albeit at a loss of generality
-        * folks who are new to pinning could use this method, and it can help us to guide the diagnostics by suggesting that they `Box::pin`
-
-[`StreamExt`]: https://docs.rs/futures/0.3/futures/stream/trait.StreamExt.html
-[`poll_next_unpin`]: https://docs.rs/futures/0.3/futures/stream/trait.StreamExt.html#method.poll_next_unpin

src/design_docs/yield_safe.md

@@ -1,28 +1 @@
 # ⚠️ Yield-safe lint
-
-## Use-case
-
-Some types should not be held across a "yield" bound. A typical example is a `MutexGuard`:
-
-```rust,ignore
-async fn example(x: &Lock<u32>) {
-    let data = x.lock().unwrap();
-    something().await;
-    *data += 1;
-}
-
-async fn something() { }
-```
-
-In practice, a lot of these issues are avoided because `MutexGuard` is not `Send`, but single-thread runtimes hit these issues.
-
-## Types where this would apply
-
-* `MutexGuard` for mutexes, read-write locks
-* Guards for ref-cells
-* Things that might use these types internally and wish to bubble it up
-
-## Precedent and related questions
-
-* The `#[must_use]` lint on types, we would want their design to work very closely.
-* Non-async-friendly functions like `sleep` or `task::block_on`.

src/vision/roadmap.md

@@ -61,8 +61,8 @@ Clicking on active initiatives also shows a list of *milestones*. These mileston
 |   ↳ tbd | 💤 | ▰▱▱▱▱▱ |
 
 [Async fn everywhere]: ./roadmap/async_fn.md
-[fundamentals]: ./roadmap/async_fn/async_fn_fundamentals.md
-[Async closures]: ./roadmap/async_fn/async_fn_fundamentals/async_closures.md
+[fundamentals]: https://rust-lang.github.io/async-fundamentals-initiative/
+[Async closures]: https://rust-lang.github.io/async-fundamentals-initiative/design-discussions/async_closures.html
 [Boxable async functions]: ./roadmap/async_fn/boxable.md
 [Async main and tests]: ./roadmap/async_fn/async_main_and_tests.md
 [Scoped spawn and reliable cancellation]: ./roadmap/scopes.md