Why does `Box` not implement the `Sink` trait when using Tokio and the experimental async/await support?
I am having a play with async/await by using Tokio with the async/await feature enabled in my Cargo.toml
(and the latest Rust nightly with 2018 edition):
tokio = { version = "0.1.11", features = ["async-await-preview"] }
I've run into an error I don't understand, which is reproduced in this minimal example:
#![feature(await_macro, async_await, futures_api)]
use tokio::prelude::*;
pub fn main() {
tokio::run_async(async {
let s: Option<Box<dyn Sink<SinkItem = u8, SinkError = ()> + Send + Sync + 'static>> = None;
if let Some(sink) = s {
await!(sink.send_async(100));
}
});
}
The error is:
error[E0277]: the trait bound `for<'r> (dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r): futures::sink::Sink` is not satisfied
--> src/main.rs:5:5
|
5 | tokio::run_async(async {
| ^^^^^^^^^^^^^^^^ the trait `for<'r> futures::sink::Sink` is not implemented for `dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send`
|
= note: required because of the requirements on the impl of `futures::sink::Sink` for `std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>`
= note: required because it appears within the type `tokio_async_await::sink::send::Send<'_, std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>>`
= note: required because it appears within the type `for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}`
= note: required because it appears within the type `[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]`
= note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]>`
= note: required because it appears within the type `impl std::future::Future`
= note: required by `tokio::async_await::run_async`
and it goes away if I remove the line beginning "await!".
When using Tokio without the experimental async/await support, my program is happy with the idea that a Box<dyn Sink>
is a Sink
, so I'm not really sure why the error crops up using async/await stuff.
What does the error mean? How can I get around this?
async-await rust rust-tokio
add a comment |
I am having a play with async/await by using Tokio with the async/await feature enabled in my Cargo.toml
(and the latest Rust nightly with 2018 edition):
tokio = { version = "0.1.11", features = ["async-await-preview"] }
I've run into an error I don't understand, which is reproduced in this minimal example:
#![feature(await_macro, async_await, futures_api)]
use tokio::prelude::*;
pub fn main() {
tokio::run_async(async {
let s: Option<Box<dyn Sink<SinkItem = u8, SinkError = ()> + Send + Sync + 'static>> = None;
if let Some(sink) = s {
await!(sink.send_async(100));
}
});
}
The error is:
error[E0277]: the trait bound `for<'r> (dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r): futures::sink::Sink` is not satisfied
--> src/main.rs:5:5
|
5 | tokio::run_async(async {
| ^^^^^^^^^^^^^^^^ the trait `for<'r> futures::sink::Sink` is not implemented for `dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send`
|
= note: required because of the requirements on the impl of `futures::sink::Sink` for `std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>`
= note: required because it appears within the type `tokio_async_await::sink::send::Send<'_, std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>>`
= note: required because it appears within the type `for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}`
= note: required because it appears within the type `[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]`
= note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]>`
= note: required because it appears within the type `impl std::future::Future`
= note: required by `tokio::async_await::run_async`
and it goes away if I remove the line beginning "await!".
When using Tokio without the experimental async/await support, my program is happy with the idea that a Box<dyn Sink>
is a Sink
, so I'm not really sure why the error crops up using async/await stuff.
What does the error mean? How can I get around this?
async-await rust rust-tokio
add a comment |
I am having a play with async/await by using Tokio with the async/await feature enabled in my Cargo.toml
(and the latest Rust nightly with 2018 edition):
tokio = { version = "0.1.11", features = ["async-await-preview"] }
I've run into an error I don't understand, which is reproduced in this minimal example:
#![feature(await_macro, async_await, futures_api)]
use tokio::prelude::*;
pub fn main() {
tokio::run_async(async {
let s: Option<Box<dyn Sink<SinkItem = u8, SinkError = ()> + Send + Sync + 'static>> = None;
if let Some(sink) = s {
await!(sink.send_async(100));
}
});
}
The error is:
error[E0277]: the trait bound `for<'r> (dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r): futures::sink::Sink` is not satisfied
--> src/main.rs:5:5
|
5 | tokio::run_async(async {
| ^^^^^^^^^^^^^^^^ the trait `for<'r> futures::sink::Sink` is not implemented for `dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send`
|
= note: required because of the requirements on the impl of `futures::sink::Sink` for `std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>`
= note: required because it appears within the type `tokio_async_await::sink::send::Send<'_, std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>>`
= note: required because it appears within the type `for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}`
= note: required because it appears within the type `[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]`
= note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]>`
= note: required because it appears within the type `impl std::future::Future`
= note: required by `tokio::async_await::run_async`
and it goes away if I remove the line beginning "await!".
When using Tokio without the experimental async/await support, my program is happy with the idea that a Box<dyn Sink>
is a Sink
, so I'm not really sure why the error crops up using async/await stuff.
What does the error mean? How can I get around this?
async-await rust rust-tokio
I am having a play with async/await by using Tokio with the async/await feature enabled in my Cargo.toml
(and the latest Rust nightly with 2018 edition):
tokio = { version = "0.1.11", features = ["async-await-preview"] }
I've run into an error I don't understand, which is reproduced in this minimal example:
#![feature(await_macro, async_await, futures_api)]
use tokio::prelude::*;
pub fn main() {
tokio::run_async(async {
let s: Option<Box<dyn Sink<SinkItem = u8, SinkError = ()> + Send + Sync + 'static>> = None;
if let Some(sink) = s {
await!(sink.send_async(100));
}
});
}
The error is:
error[E0277]: the trait bound `for<'r> (dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r): futures::sink::Sink` is not satisfied
--> src/main.rs:5:5
|
5 | tokio::run_async(async {
| ^^^^^^^^^^^^^^^^ the trait `for<'r> futures::sink::Sink` is not implemented for `dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send`
|
= note: required because of the requirements on the impl of `futures::sink::Sink` for `std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>`
= note: required because it appears within the type `tokio_async_await::sink::send::Send<'_, std::boxed::Box<dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send>>`
= note: required because it appears within the type `for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}`
= note: required because it appears within the type `[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]`
= note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:5:28: 11:6 for<'r, 's, 't0, 't1> {std::option::Option<std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 'r)>>, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 's)>, tokio_async_await::sink::send::Send<'t0, std::boxed::Box<(dyn futures::sink::Sink<SinkItem=u8, SinkError=()> + std::marker::Sync + std::marker::Send + 't1)>>, ()}]>`
= note: required because it appears within the type `impl std::future::Future`
= note: required by `tokio::async_await::run_async`
and it goes away if I remove the line beginning "await!".
When using Tokio without the experimental async/await support, my program is happy with the idea that a Box<dyn Sink>
is a Sink
, so I'm not really sure why the error crops up using async/await stuff.
What does the error mean? How can I get around this?
async-await rust rust-tokio
async-await rust rust-tokio
edited Nov 16 '18 at 1:26
Shepmaster
154k14305443
154k14305443
asked Nov 14 '18 at 14:26
jsdwjsdw
3,13321824
3,13321824
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
My fix was to wrap the Box
ed Sink
s into a newtype and implement the Sink
trait on that. I think that perhaps Box<dyn Sink>
does not implement Sink
in this nightly, which is basically what the error message implies (I guess the async/await shims redefine Sink
and don't implement it on Box
).
My wrapper ended up looking like this:
struct BoxedSink<I, E>(Box<dyn Sink<SinkItem = I, SinkError = E> + Send + Sync + 'static>);
impl<I, E> Sink for BoxedSink<I, E> {
type SinkItem = I;
type SinkError = E;
fn start_send(
&mut self,
input: Self::SinkItem,
) -> Result<AsyncSink<Self::SinkItem>, Self::SinkError> {
self.0.start_send(input)
}
fn poll_complete(&mut self) -> Poll<(), Self::SinkError> {
self.0.poll_complete()
}
}
You have to wrap your Box<Sinks>
in this to make them once again implement Sink
.
Based on chatting with some of the implementors, it sounds likeSink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the splitItem
/Error
associated types, unlikeFuture
andStream
.
– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53302482%2fwhy-does-boxdyn-sink-not-implement-the-sink-trait-when-using-tokio-and-the%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
My fix was to wrap the Box
ed Sink
s into a newtype and implement the Sink
trait on that. I think that perhaps Box<dyn Sink>
does not implement Sink
in this nightly, which is basically what the error message implies (I guess the async/await shims redefine Sink
and don't implement it on Box
).
My wrapper ended up looking like this:
struct BoxedSink<I, E>(Box<dyn Sink<SinkItem = I, SinkError = E> + Send + Sync + 'static>);
impl<I, E> Sink for BoxedSink<I, E> {
type SinkItem = I;
type SinkError = E;
fn start_send(
&mut self,
input: Self::SinkItem,
) -> Result<AsyncSink<Self::SinkItem>, Self::SinkError> {
self.0.start_send(input)
}
fn poll_complete(&mut self) -> Poll<(), Self::SinkError> {
self.0.poll_complete()
}
}
You have to wrap your Box<Sinks>
in this to make them once again implement Sink
.
Based on chatting with some of the implementors, it sounds likeSink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the splitItem
/Error
associated types, unlikeFuture
andStream
.
– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
add a comment |
My fix was to wrap the Box
ed Sink
s into a newtype and implement the Sink
trait on that. I think that perhaps Box<dyn Sink>
does not implement Sink
in this nightly, which is basically what the error message implies (I guess the async/await shims redefine Sink
and don't implement it on Box
).
My wrapper ended up looking like this:
struct BoxedSink<I, E>(Box<dyn Sink<SinkItem = I, SinkError = E> + Send + Sync + 'static>);
impl<I, E> Sink for BoxedSink<I, E> {
type SinkItem = I;
type SinkError = E;
fn start_send(
&mut self,
input: Self::SinkItem,
) -> Result<AsyncSink<Self::SinkItem>, Self::SinkError> {
self.0.start_send(input)
}
fn poll_complete(&mut self) -> Poll<(), Self::SinkError> {
self.0.poll_complete()
}
}
You have to wrap your Box<Sinks>
in this to make them once again implement Sink
.
Based on chatting with some of the implementors, it sounds likeSink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the splitItem
/Error
associated types, unlikeFuture
andStream
.
– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
add a comment |
My fix was to wrap the Box
ed Sink
s into a newtype and implement the Sink
trait on that. I think that perhaps Box<dyn Sink>
does not implement Sink
in this nightly, which is basically what the error message implies (I guess the async/await shims redefine Sink
and don't implement it on Box
).
My wrapper ended up looking like this:
struct BoxedSink<I, E>(Box<dyn Sink<SinkItem = I, SinkError = E> + Send + Sync + 'static>);
impl<I, E> Sink for BoxedSink<I, E> {
type SinkItem = I;
type SinkError = E;
fn start_send(
&mut self,
input: Self::SinkItem,
) -> Result<AsyncSink<Self::SinkItem>, Self::SinkError> {
self.0.start_send(input)
}
fn poll_complete(&mut self) -> Poll<(), Self::SinkError> {
self.0.poll_complete()
}
}
You have to wrap your Box<Sinks>
in this to make them once again implement Sink
.
My fix was to wrap the Box
ed Sink
s into a newtype and implement the Sink
trait on that. I think that perhaps Box<dyn Sink>
does not implement Sink
in this nightly, which is basically what the error message implies (I guess the async/await shims redefine Sink
and don't implement it on Box
).
My wrapper ended up looking like this:
struct BoxedSink<I, E>(Box<dyn Sink<SinkItem = I, SinkError = E> + Send + Sync + 'static>);
impl<I, E> Sink for BoxedSink<I, E> {
type SinkItem = I;
type SinkError = E;
fn start_send(
&mut self,
input: Self::SinkItem,
) -> Result<AsyncSink<Self::SinkItem>, Self::SinkError> {
self.0.start_send(input)
}
fn poll_complete(&mut self) -> Poll<(), Self::SinkError> {
self.0.poll_complete()
}
}
You have to wrap your Box<Sinks>
in this to make them once again implement Sink
.
edited Nov 16 '18 at 1:28
Shepmaster
154k14305443
154k14305443
answered Nov 14 '18 at 21:48
jsdwjsdw
3,13321824
3,13321824
Based on chatting with some of the implementors, it sounds likeSink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the splitItem
/Error
associated types, unlikeFuture
andStream
.
– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
add a comment |
Based on chatting with some of the implementors, it sounds likeSink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the splitItem
/Error
associated types, unlikeFuture
andStream
.
– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
Based on chatting with some of the implementors, it sounds like
Sink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the split Item
/ Error
associated types, unlike Future
and Stream
.– Shepmaster
Nov 16 '18 at 1:29
Based on chatting with some of the implementors, it sounds like
Sink
is not an abstraction that is going to continue to exist in the new futures world. You can tell it hasn't been updated because it still has the split Item
/ Error
associated types, unlike Future
and Stream
.– Shepmaster
Nov 16 '18 at 1:29
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
Thanks, that's interesting to know. I am maybe a bit surprised that Stream would continue to exist but not Sink (piping Streams to Sinks seems useful for instance, though easy with async/await I guess!), but Sink does feel like the least useful of the abstractions to keep around!
– jsdw
Nov 20 '18 at 7:39
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53302482%2fwhy-does-boxdyn-sink-not-implement-the-sink-trait-when-using-tokio-and-the%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown