futures-rs
                                
                                
                                
                                    futures-rs copied to clipboard
                            
                            
                            
                        Merge futures-util and futures-executor to main futures crate
I would propose to merge these utility crates to the main futures crate. There are some reasons:
futuresandfutures-utilare 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 
futuresseems due tofutures-util, and the compile time reduction by splitting the crate doesn't seem to work very well. - Since 
futures-executoralso depends onfutures-util, it doesn't seem to have much compile time advantage even if used individually. - As said in https://github.com/rust-lang/futures-rs/issues/1875#issuecomment-639895854, if 
futuresandfutures-utilare different crates, it seems impossible to add optional features tofuturesper 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.
Sounds good to me assuming they're feature gated.
futures-channelis 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 
channelmodule 
- enable 
 executor- enable 
executormodule 
- enable 
 future-util(or justfuture)- enable utilities in 
futuremodule Futuretrait is available regardless of whether the feature is enabled.
- enable utilities in 
 io- enable 
iomodule 
- enable 
 lock- enable 
lockmodule 
- enable 
 sink- enable 
sinkmodule 
- enable 
 stream-util(or juststream)- enable utilities in 
streammodule Streamtrait is available regardless of whether the feature is enabled.
- enable utilities in 
 task-util(or justtask)- enable utilities in 
taskmodule Poll,Context,Wakeretc. are available regardless of whether the feature is enabled.- (I haven't decided how to handle the spawn trait...)
 
- enable utilities in 
 
(I'll open a new issue about this later.)
To make backporting to 0.3 easier, I will block this for now.