Open taiki-e opened 3 years ago
Sounds good to me assuming they're feature gated.
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
channel
moduleexecutor
executor
modulefuture-util
(or just future
)
future
moduleFuture
trait is available regardless of whether the feature is enabled.io
io
modulelock
lock
modulesink
sink
modulestream-util
(or just stream
)
stream
moduleStream
trait is available regardless of whether the feature is enabled.task-util
(or just task
)
task
modulePoll
, Context
, Waker
etc. are available regardless of whether the feature is enabled.(I'll open a new issue about this later.)
To make backporting to 0.3 easier, I will block this for now.
I would propose to merge these utility crates to the main
futures
crate. There are some reasons:futures
andfutures-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.futures
seems due tofutures-util
, and the compile time reduction by splitting the crate doesn't seem to work very well.futures-executor
also depends onfutures-util
, it doesn't seem to have much compile time advantage even if used individually.futures
andfutures-util
are different crates, it seems impossible to add optional features tofutures
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.