Document not found (404)
+This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +Thanks to everyone who helped forming the future of Rust async.
+Thanks to everyone who helped writing Stories by participating in one of the Async Rust writing sessions.
+Thanks to everyone who discussed about stories, shiny future and new features.
+Thanks to everyone who opened a Pull Request and wrote a story, shiny future or improved the organization of the repository.
+This section contains notes and summaries from conversations that we have had with people are using Rust and async and describing their experiences. These conversations and links are used as "evidence" when building the "status quo" section.
+This section is not meant to be an "exhaustive list" of all sources. That would be impossible. Many conversations are short, not recorded, and hard to summaize. Others are subject to NDA. We certainly don't require that all claims in the status quo section are backed by evidence found here. Still, it's useful to have a place to dump notes and things for future reference.
+ +Notes taken from the thread in response to Niko's tweet.
+for await (variable of iterable) would be nice.join and Result play poorly together
+Result?The design documents (or "design docs", more commonly) describe potential designs. These docs vary greatly in terms of their readiness to be implemented:
+In the early stages, design docs are meant to capture interesting bits of "async design space". They are often updated to capture the results of a fruitful conversation or thread which uncovered contraints or challenges in solving a particular problem. They will capture a combination of the following:
+As a design progresses, the doc should get more and more complete, until it becomes something akin to an RFC. (Often, at that point, we will expand the design document into a directory, adding an actual RFC draft and other contents; those things can live in this repo or elsewhere, depending.) Once we decide to put a design doc onto the roadmap, it will also contain links to tracking issues or other places to track the status.
+ +trait Foo {
+ // Currently disallowed:
+ async fn bar();
+}
+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.
Send on futuresasync 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:
+trait Service {
+ async fn request(&self);
+}
+
+fn parallel_service<S: Service>()
+where
+ S::Future: Send,
+{
+ ...
+}
+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 { .. }
+ }
+}
+trait MyMethod {
+ async fn foo(&self);
+}
+gen fn that contains yieldnext ("resume args")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)
+ }
+}
+Sometimes streams need to reuse internal storage (Discussion).
+StreamExt module.poll_next_unpin can make working with pin easier, albeit at a loss of generality
+Box::pinSome types should not be held across a "yield" bound. A typical example is a MutexGuard:
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.
MutexGuard for mutexes, read-write locks#[must_use] lint on types, we would want their design to work very closely.sleep or task::block_on.Welcome to the wg-async-foundations website!
+The leads of this working group are @tmandry and @nikomatsakis. Both of them can be found on Zulip.
+There is a weekly triage meeting that takes place in our Zulip stream. Feel free to stop by then (or any time!) to introduce yourself.
+If you're interested in fixing bugs, though, there is no need to wait for the meeting! Take a look at the instructions here.
+This working group is focused around implementation/design of the โfoundationsโ for Async I/O. This means that we are focused on designing and implementing extensions to the language, standard library, and other "core" bits of support offered by the Rust organization. We do not directly work on external projects like tokio, async-std, smol, embassy and so forth, although we definitely discuss ideas and coordinate with them where appropriate.
+We hold discussions on the #wg-async-foundations stream in Zulip
Licensed under either of
+at your option.
+Unless you explicitly state otherwise, any contribution intentionally submitted +for inclusion in this crate by you, as defined in the Apache-2.0 license, shall +be dual licensed as above, without any additional terms or conditions.
+ +