Futures-rs: Receiver::Error should be something like Never or Nothing

[stepancheg]

enum Nothing {}

impl Stream for Receiver<T> {
    type Error = Nothing;
}

To clearly state that poll never fails.

[stepancheg]

BTW, tokio_core::reactor::Handle::spawn future parameter Error should probably be Nothing too.

[stepancheg]

... and Executor impl for CpuPool too.

Currently it has signature

impl<F> Executor<F> for CpuPool
    where F: Future<Item = (), Error = ()> + Send + 'static,

Which gives user false sense that it is OK to return error. While it is not, error must be handled inside the future.

[srijs]

FWIW Elm uses Never as the name for this type, to signify that a certain task for instance can "never" fail. I always thought that particular name worked quite well.

[jimmycuadra]

When it's eventually stable, the never type (!) would be ideal for this.

[alexcrichton]

I wrote in https://github.com/alexcrichton/futures-rs/issues/554:

---

Right now there's a number of locations in this library where () is used as an error type

• BiLock::acquire
• unsync::mpsc::Receiver
• unsync::mpsc::UnboundedReceiver
• sync::mpsc::Receiver
• sync::mpsc::UnboundedReceiver
• Sink for Vec<T>

I've also heard of this being common enough throughout the ecosystem that I think we should provide a solution to this! I think we'll want to not "just add a Void" type but also make sure it's at least reasonably ergonomic to use. For example I think we should add:

enum Void {}
Void::into(self) -> T
Future<Item=T, Error=Void>::poll_ok(&mut self) -> Async<T>
Future<Item=T, Error=Void>::wait_ok(self) -> T

And maybe more! I'm curious to hear what others think about adding such APIs.

[alexcrichton]

I wouldn't mind trying to game this out before an 0.2 release. We can't change existing types but we could add the type for external libraries to use, as well as the extra goodies on the Future trait itself!

[jimmycuadra]

Is there no hope of the never type being stabilized in a time frame that would make it reasonable to just wait on this issue rather than introduce a futures-specific void type?

[alexcrichton]

AFAIK yeah, the stabilization story for ! is quite long-term still

[srijs]

@alexcrichton Are you saying you would consider a PR adding Void to this crate in order for dependent libraries to use, plus a few utilities (converting Future<Error=Void> to any Future<Error=A> comes to mind)? If so, I'd be interested in picking this up.

[alexcrichton]

Certainly! Unfortunately we can't land a breaking change right now so we can't change the type Error = ();, but we could start paving the road for future implementations!

[rustonaut]

@jimmycuadra I havent looked to deep into ! but shouldn't it be possible to use the Never type (which by now is in the tokio 0.2 branch) and once it's stable change Never to wrap ! (i.e. struct Never(!)). I would
guess that should give the same benefit's then directly using ! while keeping backward compability intact (e.g. someone might implement a trait on both Never and ! which "somehow" conflicts with implementing it on !)

~@alexcrichton does that mean it will change for the v0.2 release or that it will stay () and just new or otherwise changed API's will get the change?.~

I was looking at a not up-to-date version of v0.2, the changes are there by now.
(so this Issue can be closed?)

[aturon]

This has been done for 0.2.