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

Add future::poll_fn #123

Closed
wants to merge 2 commits into from
Closed

Add future::poll_fn #123

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Aug 28, 2019

No description provided.

@ghost ghost requested a review from yoshuawuyts August 28, 2019 20:33
@kpp
Copy link
Contributor

kpp commented Aug 28, 2019

Why not pub use futures? Why do you keep your own Stream impl with fn next which collides with async_std::Stream and futures::StreamExt? (#23).

@ghost
Copy link
Author

ghost commented Aug 28, 2019

@kpp It's because we want to provide stronger stability guarantees, a more faithful feel of std than what futures has to offer, and more polished documentation that fits better into async-std.

We're still compatible with traits Stream, AsyncRead, AsyncWrite, and AsyncSeek from the futures crate, but don't think the extension traits like FutureExt or StreamExt have been polished enough to be worth exporting here. After all, the 0.3 version of futures has been unstable for a very long time and we want to be commit to stability in less than a month (on Sep 26).

@berkus
Copy link

berkus commented Aug 29, 2019

Committing to stability of unstable features may be not the right idea. I understand that std should feel stable, but it's as stable as its constituent parts - and async-std has at least half of it pretty unstable still.

@yoshuawuyts yoshuawuyts mentioned this pull request Aug 29, 2019
@yoshuawuyts
Copy link
Contributor

I'm not sure why folks are downvoting the clarification from @stjepang, async-std's principal designer. Being able to provide a consistent API surface is literally this crate's reason for existing. Defining most of our own types allows us to control our stability guarantees and user experience. It's a fundamental design principle that underpins all of this crate.

We're committed to providing an ergonomic async counterpart to stdlib that's fully compatible with the core traits and async ecosystem underpinned by futures-rs. All solutions around how to use futures-rs have tradeoffs, and we feel comfortable with the path we've chosen.

So I'd like to take a moment here to provide some clarity: we're happy to answer any questions about design in earnest, but we're not going to change the design direction of this crate. If this is something you disagree with, that's okay -- but it might be good to realize this crate is not for you.

I hope this makes sense; I prefer being clear on these kinds of matters for the benefit of everyone involved.


@stjepang lol I just wrote #124 with the exact same API. Seems like we had the same idea at the same time!

@ghost
Copy link
Author

ghost commented Sep 8, 2019

Closing in favor of #124

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants