Merge branch 'master' of github.com:async-std/async-std

.travis.yml

@@ -14,6 +14,7 @@ matrix:
       env: BUILD_DOCS=1
     - rust: nightly
       os: osx
+      osx_image: xcode9.2
       env: BUILD_DOCS=1
     - rust: nightly-x86_64-pc-windows-msvc
       os: windows

Cargo.toml

@@ -36,6 +36,7 @@ mio-uds = "0.6.7"
 num_cpus = "1.10.0"
 pin-utils = "0.1.0-alpha.4"
 slab = "0.4.2"
+surf = "1.0.1"
 
 [dev-dependencies]
 femme = "1.1.0"

docs/src/concepts/futures.md

@@ -10,7 +10,7 @@ Luckily, concurrent Rust already has two well-known and effective concepts abstr
 
 As a quick summary:
 
-- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access.
+- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side, and expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access.
 
 - `Sync` is about *sharing data* between two concurrent parts of a program. This is another common pattern: as writing to a memory location or reading while another party is writing is inherently unsafe, this access needs to be moderated through synchronisation.[^1] There are many common ways for two parties to agree on not using the same part in memory at the same time, for example mutexes and spinlocks. Again, Rust gives you the option of (safely!) not caring. Rust gives you the ability to express that something *needs* synchronisation while not being specific about the *how*.
 

docs/src/concepts/tasks.md

@@ -63,10 +63,10 @@ Tasks in `async_std` are one of the core abstractions. Much like Rust's `thread`
 
 - They are allocated in one single allocation
 - All tasks have a *backchannel*, which allows them to propagate results and errors to the spawning task through the `JoinHandle`
-- The carry useful metadata for debugging
+- They carry useful metadata for debugging
 - They support task local storage
 
-`async_std`s task api handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started.
+`async_std`s task API handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started.
 
 ## Blocking
 

examples/surf-web.rs

@@ -0,0 +1,21 @@
+//! Sends an HTTP request to the Rust website.
+
+#![feature(async_await)]
+
+use async_std::task;
+
+fn main() -> Result<(), surf::Exception> {
+    task::block_on(async {
+        let url = "https://www.rust-lang.org";
+        let mut response = surf::get(url).await?;
+        let body = response.body_string().await?;
+
+        dbg!(url);
+        dbg!(response.status());
+        dbg!(response.version());
+        dbg!(response.headers());
+        dbg!(body.len());
+
+        Ok(())
+    })
+}