Consider flattening the crate and dropping -preview status

[aturon]

As the std version of the Future trait heads toward stabilization, there are a couple questions we should revisit in terms of the organization of this crate:

• First, we're close to the point where I think it'd make sense to move futures 0.1 to a different crate name (futures-old or some such), and put out a 0.3.0-beta release on futures proper.

• Second, with 0.2 we split up the crate into a bunch of sub-crates to allow for easier iteration on the core APIs. At this point, though, we've had quite a bit of iteration and experience using these APIs with async/await/borrowing. We should consider re-flattening the crates, as well as the extension traits (especially AsyncRead{Ext}, AsyncWrite{Ext}). Doing so would streamline the user experience.

Thoughts?

[Nemo157]

By flattening do you mean merging all the crates into futures, or keeping some of the existing boundaries?

As far as I'm aware a major reason for the separate sub-crates was to allow semver breaking updates to parts of the API without causing pain in the ecosystem. Using sub-crates to denote this is also good for future compatibility with public/private dependencies, futures-core is intended to be stable long term so can be a public dependency, while futures-util (and by extension futures) can release relatively rapid breaking changes so should be kept as a private dependency (and existential types should make that trivial to do while still returning a combinator based future without a manually written wrapper).

It could make sense to reduce the number of crates drastically though. Maybe even as far as just 3 crates: futures-core as the almost 100% stable core, futures for everything that may require breaking changes and futures-test for testing specific utilities. Basically I guess that would be merging futures-io into futures-core (is it stable enough for this now?) and everything except futures-test directly into futures.

Migrating the uncontroversial functions from the extension traits onto the actual traits could make a lot of sense. I assume there's no major plan that would block this now, like waiting for GATs + existential types so that methods like Stream::next could return an associated type to allow implementors to provide a more optimized implementation instead of the default?

I assume part of the intention with having the separate levels of update schedule would be to migrate other utilities into the more stable crates over time. Taking the same example of moving StreamExt::next onto Stream directly, this will cause conflicts when users have both Stream::next and StreamExt::next in scope; so having a plan to deal with this seems necessary if the intention is to migrate functions after release.

[Nemo157]

Relevant discussion from back around 0.3.0-alpha.1: #1071

[cramertj]

I still feel like channels are less stable than the traits in core, and that Sink is less stable than channels. I have basically no opinion about the futures vs. futures-util split.

in the end though, all I really care about is keeping a -util for fast iteration on new features and combinators that aren't subject to the same stability requirements as the Stream trait and channels.

[cramertj]

There's been quite a bit of discussion since. -preview is going away soon, but the separate crates will remain for greater control over versioning.