Closed
Description
If you have a variable with type impl TryStream<Ok=T, Error=E>
and want to use it as a impl Stream<Item=Result<T,E>>
, the compiler complains.
The compiler does not take you by the hand and helps you with helpful hints.
I tried (roughly) this code: (EDIT: find a self-contained example here)
use bytes;
use std::io;
use futures::channel::mpsc;
use async_std::task;
//pub fn my_rx(sock: std::sync::Arc<UdpSocket>) -> impl futures::Stream<Item=Result<(bytes::Bytes, std::net::SocketAddr), std::io::Error>> { // WORKS
pub fn my_rx(sock: std::sync::Arc<UdpSocket>) -> impl futures::TryStream<Ok=(bytes::Bytes, std::net::SocketAddr), Error=std::io::Error> { // ERROR
...
}
fn main() {
let inet_rx = my_rx();
let (tx1, inet_rx1) = mpsc::unbounded();
let (tx2, inet_rx2) = mpsc::unbounded();
let mut tx = tx1.fanout(tx2).sink_map_err(|_| io::Error::new(io::ErrorKind::Other, "Send Error"));
let foo = inet_rx.forward(tx);
let _ = task::spawn(foo);
}
I expected to see this happen:
I would like the compiler to tell me that that that while there exists an implementation of TryStream<Ok=T, Error=E>
as Stream<Result<T,E>>
, there might exist other implementations and therefore this code is not accepted. Using Stream<Result<T,E>>
instead of TryStream<Ok=T, Error=E>
would solve the error.
Instead, this happened:
There are no hints by the compiler.
Meta
rustc --version --verbose
:
rustc 1.41.0-nightly (6d77e45f0 2019-12-04)
binary: rustc
commit-hash: 6d77e45f01079fe3d40180b3e256e414ab379f63
commit-date: 2019-12-04
host: x86_64-unknown-linux-gnu
release: 1.41.0-nightly
LLVM version: 9.0
Activity
jonas-schievink commentedon Apr 11, 2020
Please provide a self-contained example that shows the bad diagnostic
manuels commentedon Apr 12, 2020
I tried to break it down to this code:
manuels commentedon Apr 12, 2020
I just found out that defining
Stream::Item
by hand also works:Why is that? Is the compiler not able to deduce
Stream::Item
by itself?Maybe the compiler should give a hint that declaring
Stream::Item
yourself would solve the problem.You might argue that the error message
does exactly this but it's not directly clear how to do this. Maybe giving an example like
would be helpful here.
estebank commentedon Apr 14, 2020
I think that #71108 might fulfill the last comment's request.
Edit: I just checked and the code doesn't account for
impl Trait
in return position (which behaves differently toimpl Trait
in argument position, which is handled). I'll see what I can do to also handle this case.Edit 2: This will not be handled in the linked PR, it is a second order projection that will need further work for me to be able to supply a structured suggestion.
Edit 3: Managed to get it to work 🎉
It's a bit more verbose than I'd like, but we can tackle on a different PR.
Suggest constraint on `impl Trait` in return type
Auto merge of rust-lang#71108 - estebank:suggest-proj-type-mismatch-c…