Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core::spawn should expect Error=Void not Error=() #197

Open
Rufflewind opened this issue Apr 14, 2017 · 5 comments
Open

Core::spawn should expect Error=Void not Error=() #197

Rufflewind opened this issue Apr 14, 2017 · 5 comments

Comments

@Rufflewind
Copy link

Since spawn never looks at the results of the future, the return value ought to be completely devoid of any useful information to reduce the risk that the user might unintentionally forget about the result.

The current choice of Future<Item=(), Error=()> still has one bit of information: it’s possible to distinguish between Ok(()) and Err(()) results. It really ought to return Future<Item=(), Error=Void>, which means the Future is guaranteed to succeed.

It’s not a big problem by any means, just kind of quirky in my perspective.

@alexcrichton
Copy link
Contributor

Yes unfortunately there's no shared "void" type right now across these libraries. The futures crate for example has a number of situations where the error should be void vs () as it is today.

This is something that we'll definitely want to evaluate for futures 0.2

@vks
Copy link

vks commented May 3, 2017

What about using the void crate?

@carllerche
Copy link
Member

I don't think we want to pull in another crate. Either way, changing the type will be a breaking change which requires a version bump.

I think at this point, we'll be better off waiting for upcoming changes to rust-lang to hit stable.

@srijs
Copy link
Contributor

srijs commented Aug 28, 2017

Just for reference, this is being discussed in futures as well: rust-lang/futures-rs#476

If futures ended up exporting Void I suppose tokio could leverage that?

@alexcrichton
Copy link
Contributor

Indeed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants