Tags: busarovalex/futures-rs
Tags
Version 0.1.15 * Improve performance of `BiLock` methods * Implement `Clone` for `FutureResult` * Forward `Stream` trait through `SinkMapErr` * Add `stream::futures_ordered` next to `futures_unordered` * Reimplement `Stream::buffered` on top of `stream::futures_ordered` (much more efficient at scale). * Add a `with_notify` function for abstractions which previously required `UnparkEvent`. * Add `get_ref`/`get_mut`/`into_inner` functions for stream take/skip methods * Add a `Clone` implementation for `SharedItem` and `SharedError` * Add a `mpsc::spawn` function to spawn a `Stream` into an `Executor` * Add a `reunite` function for `BiLock` and the split stream/sink types to rejoin two halves and reclaim the original item. * Add `stream::poll_fn` to behave similarly to `future::poll_fn` * Add `Sink::with_flat_map` like `Iterator::flat_map` * Bump the minimum Rust version to 1.13.0 * Expose `AtomicTask` in the public API for managing synchronization around task notifications. * Unify the `Canceled` type of the `sync` and `unsync` modules. * Deprecate the `boxed` methods. These methods have caused more confusion than they've solved historically, so it's recommended to use a local extension trait or a local helper instead of the trait-based methods. * Deprecate the `Stream::merge` method as it's less ergonomic than `select`. * Add `oneshot::Sender::is_canceled` to test if a oneshot is canceled off a task. * Deprecates `UnboundedSender::send` in favor of a method named `unbounded_send` to avoid a conflict with `Sink::send`. * Deprecate the `stream::iter` function in favor of an `stream::iter_ok` adaptor to avoid the need to deal with `Result` manually. * Add an `inspect` function to the `Future` and `Stream` traits along the lines of `Iterator::inspect`
Version 0.1.14
This is a relatively large release of the `futures` crate, although much of it
is from reworking internals rather than new APIs. The banner feature of this
release is that the `futures::{task, executor}` modules are now available in
`no_std` contexts! A large refactoring of the task system was performed in
PR rust-lang#436 to accomodate custom memory allocation schemes and otherwise remove
all dependencies on `std` for the task module. More details about this change
can be found on the PR itself.
Other API additions in this release are:
* A `FuturesUnordered::push` method was added and the `FuturesUnordered` type
itself was completely rewritten to efficiently track a large number of
futures.
* A `Task::will_notify_current` method was added with a slightly different
implementation than `Task::is_current` but with stronger guarantees and
documentation wording about its purpose.
* Many combinators now have `get_ref`, `get_mut`, and `into_inner` methods for
accessing internal futures and state.
* A `Stream::concat2` method was added which should be considered the "fixed"
version of `concat`, this one doesn't panic on empty streams.
* An `Executor` trait has been added to represent abstracting over the concept
of spawning a new task. Crates which only need the ability to spawn a future
can now be generic over `Executor` rather than requiring a
`tokio_core::reactor::Handle`.
As with all 0.1.x releases this PR is intended to be 100% backwards compatible.
All code that previously compiled should continue to do so with these changes.
As with other changes, though, there are also some updates to be aware of:
* The `task::park` function has been renamed to `task::current`.
* The `Task::unpark` function has been renamed to `Task::notify`, and in general
terminology around "unpark" has shifted to terminology around "notify"
* The `Unpark` trait has been deprecated in favor of the `Notify` trait
mentioned above.
* The `UnparkEvent` structure has been deprecated. It currently should perform
the same as it used to, but it's planned that in a future 0.1.x release the
performance will regress for crates that have not transitioned away. The
primary primitive to replace this is the addition of a `push` function on the
`FuturesUnordered` type. If this does not help implement your use case though,
please let us know!
* The `Task::is_current` method is now deprecated, and you likely want to use
`Task::will_notify_current` instead, but let us know if this doesn't suffice!
PreviousNext