209: add feature guards for unstable features r=yoshuawuyts a=yoshuawuyts
Makes sure unstable features aren't accidentally usable without their corresponding flags. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
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
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>
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>
190: Clean up the fs module and a few other places r=stjepang a=stjepang
Just a cleanup for various pieces of documentation, mainly around the `lib.rs` docs, the prelude, and the `fs` module. Some small bugs are also fixed along the way.
This PR is the first one in a series of review PRs that I will be submitting before the upcoming 1.0 release.
200: expose IoSlice, IoSliceMut r=stjepang a=yoshuawuyts
Exposes `io::IoSlice` and `io::IoSliceMut`. Given we're returning these from `read_vectored` and `write_vectored` it might make sense to just include them as part of our re-exports. Thanks!
Ref #131.
Co-authored-by: Stjepan Glavina <stjepang@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
196: Remove more Unpin bounds for Stream::scan r=stjepang a=tirr-c
cc #192. I missed the bounds on `Stream::scan` itself.
Co-authored-by: Wonwoo Choi <chwo9843@gmail.com>
171: Add BufRead::consume r=stjepang a=yoshuawuyts
Ref #131. This implements `BufReader::consume`. Thanks!
Note on `fill_buf`: I couldn't get the `async fn fill_buf()` to work, but tracked progress for it here: https://gist.github.com/yoshuawuyts/09bbdc7823225ca96b5e35cd1da5d581. Got some lifetimes isssues. If anyone wants to give this a shot, please do!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
192: Add Stream::scan r=stjepang a=tirr-c
Ref #129. The mapper function `f` is synchronous and returns bare `Option<B>`.
Asynchronous `f` seems tricky to implement right. It requires the wrapper to be self-referential, as a reference to internal state may be captured by the returned future.
Co-authored-by: Wonwoo Choi <chwo9843@gmail.com>
177: implement DoubleEndedStream r=yoshuawuyts a=yoshuawuyts
Ref #129. This is the most basic version of the `DoubleEndedStream` trait. Because there is no counterpart in `futures-rs` we allow this to be implementable (not sure if we should though?).
This is not a high-priority trait to implement, with probably the most useful addition being the blanket impl over [`std::iter::Fuse`](https://doc.rust-lang.org/std/iter/struct.Fuse.html) (where we should have a `Fuse` counterpart for `Stream` also).
So I'm taking this one step at the time, and this PR introduces just the bare minimum to get things working. Thanks!
r? @stjepang @taiki-e
## Refs
- https://doc.rust-lang.org/std/iter/trait.DoubleEndedIterator.html
- #129
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
184: housekeeping after 145 r=yoshuawuyts a=montekki
Now that #145 is merged combinators can follow.
1. All combinators taking `&mut self` should imply `Self: Pin`.
2. Trait bounds are to `Stream`
3. Cleans up docs and `Debug` derives.
Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
