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

Merge futures-util and futures-executor to main futures crate #2295

Open
taiki-e opened this issue Dec 22, 2020 · 3 comments
Open

Merge futures-util and futures-executor to main futures crate #2295

taiki-e opened this issue Dec 22, 2020 · 3 comments
Labels
S-blocked Status: Blocked on something else S-needs-api-design Status: Before implementing this, a discussion or decision on the new API is needed.

Comments

@taiki-e
Copy link
Member

taiki-e commented Dec 22, 2020

I would propose to merge these utility crates to the main futures crate. There are some reasons:

  • futures and futures-util are almost the same except that futures provide executors and channels. Also, both modules (executor and channel) seem to be relatively easy to make optional.
  • Most of the compile time for futures seems due to futures-util, and the compile time reduction by splitting the crate doesn't seem to work very well.
  • Since futures-executor also depends on futures-util, it doesn't seem to have much compile time advantage even if used individually.
  • As said in Add more optional features to the main futures crate #1875 (comment), if futures and futures-util are different crates, it seems impossible to add optional features to futures per module.
    (I don't plan to add a "util" feature that enables the utility itself, but I would like to add features to enable per module in the next major version.)

futures-channel is also a "utility crate", but it's almost independent, so I'm not sure if merging it is really preferable.

@taiki-e taiki-e added this to the futures-0.4 milestone Dec 22, 2020
@Nemo157
Copy link
Member

Nemo157 commented Dec 22, 2020

Sounds good to me assuming they're feature gated.

@taiki-e
Copy link
Member Author

taiki-e commented Jan 1, 2021

futures-channel is also a "utility crate", but it's almost independent, so I'm not sure if merging it is really preferable.

Given that futures-channel currently depends on futures-core's internal API, it probably makes sense to merge futures-channel into futures as well. This also allows AtomicWaker to move from futures-core to futures.

assuming they're feature gated.

For now, I'm considering adding the following features:

  • channel
    • enable channel module
  • executor
    • enable executor module
  • future-util (or just future)
    • enable utilities in future module
    • Future trait is available regardless of whether the feature is enabled.
  • io
    • enable io module
  • lock
    • enable lock module
  • sink
    • enable sink module
  • stream-util (or just stream)
    • enable utilities in stream module
    • Stream trait is available regardless of whether the feature is enabled.
  • task-util (or just task)
    • enable utilities in task module
    • Poll, Context, Waker etc. are available regardless of whether the feature is enabled.
    • (I haven't decided how to handle the spawn trait...)

(I'll open a new issue about this later.)

@taiki-e
Copy link
Member Author

taiki-e commented May 6, 2021

To make backporting to 0.3 easier, I will block this for now.

@taiki-e taiki-e added the S-blocked Status: Blocked on something else label May 6, 2021
@taiki-e taiki-e added S-needs-decision Status: A decision on whether or not to do this is needed. S-needs-api-design Status: Before implementing this, a discussion or decision on the new API is needed. and removed S-needs-decision Status: A decision on whether or not to do this is needed. labels Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: Blocked on something else S-needs-api-design Status: Before implementing this, a discussion or decision on the new API is needed.
Projects
None yet
Development

No branches or pull requests

2 participants