167: add io::cursor r=stjepang a=yoshuawuyts
Adds `io::Cursor` and makes it so `io::prelude::*` behaves the way it does in std (so it can actually be implemented - though this might just have been a bug on my side??).
Ref #131. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
207: Added the ability to collect a stream of results r=yoshuawuyts a=sunjay
As requested here: https://twitter.com/yoshuawuyts/status/1174026374316773377
The standard library has a very useful implementation of `FromIterator` that takes an iterator of `Result<T, E>` values and is able to produce a value of type `Result<Vec<T>, E>`. I asked for this in `async-std` and @yoshuawuyts recommended that I contribute the impl. It turns out that the implementation in the standard library is even more general than I initially thought. It allows any collection that implements `FromIterator` to be collected from an iterator of `Result<T, E>` values. That means that you can collect into `Result<Vec<T>, E>`, `Result<HashSet<T>, E>`, etc.
I wanted to add a similarly generic impl for this crate so we can also support collecting into any collection that implements `FromStream`.
The implementation for this is based heavily on [what exists in `std`](9150f844e2/src/libcore/result.rs (L1379-L1429)). I made a new `result` module since that's where this impl is in `std`. I still wanted to maintain the conventions of this repo, so I copied the `vec` module that @yoshuawuyts created in #125. Much like in that PR, the new `result` module is private.
There is a doctest in the documentation for `collect` that both teaches that this feature exists and tests that it works in some simple cases.
## Documentation Screenshot
![image](https://user-images.githubusercontent.com/530939/65075935-de89ae00-d965-11e9-9cd6-8b19b694ed3e.png)
Co-authored-by: Sunjay Varma <varma.sunjay@gmail.com>
40: Add initial Fuse implementation for Stream r=yoshuawuyts a=spacejam
@matklad does this address your use case?
Co-authored-by: Tyler Neely <tyler.neely@ferrous-systems.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
205: Implement simple work stealing r=yoshuawuyts a=stjepang
This is our first version of a work-stealing scheduler. We won't stop here, there is still lots of room for improvement.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
125: from/into stream r=yoshuawuyts a=yoshuawuyts
This adds `Stream` counterparts to `FromIterator`, `IntoIterator` and `Iterator::collect`, allowing to use the same patterns that are common in streams. Thanks!
## Tasks
- [x] `FromStream`
- [x] `IntoStream`
- [x] `Stream::collect`
## Screenshot
![Screenshot_2019-08-29 async_std stream - Rust](https://user-images.githubusercontent.com/2467194/63928985-ec2bd200-ca50-11e9-868c-9899800e5b83.png)
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
180: adds stream::fold combinator r=stjepang a=montekki
Fold. Kind of clumsy around the part with the option and moving out of the shared context.
___
Stdlib: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.fold
Ref: #129
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
203: expose std::pin r=yoshuawuyts a=yoshuawuyts
This is important when defining / calling futures, so it makes sense for us to also export this.
But also given recent user feedback on the confusion on pinning, I'd like to open up the possibility to experiment with providing better pinning facilities such as [`pin-project`](https://github.com/taiki-e/pin-project) or [`pin_mut`](https://docs.rs/pin-utils/0.1.0-alpha.4/pin_utils/macro.pin_mut.html) behind flags. I'm not sure if we could, or even should. But I want to allow us to have that conversation and test things out (even if it's just in floating patches.)
Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>