Futures-rs: Why are there extension traits for Future and Stream, when the methods could be on the original trait?

[lachlansneff]

For example, the Iterator trait has pre-defined methods on it that are available automatically for all Iterator implementations. The FutureExt trait is automatically defined for all implementations of Future, but why not just have those methods on the Future trait instead. It would also mean that you wouldn't have to import both traits if you want to use combinators.

[Nemo157]

Having methods directly on Future would not allow experimenting outside of std like this, these combinators would have to be defined in std and would be instantly stable. This way we can release breaking changes of futures-util without affecting downstream crates (as long as they do not publicly expose types from futures-util). The same reasoning applies to the separation of Stream in futures-core and the extension trait in futures-util, the plan is to not have a breaking change of futures-core (at least for a very long time) so that downstream crates can pass impl Stream types between each other without being affected by breaking changes in futures-util.

You could consider futures-util like itertools, an experimental expansion of the 0 combinators currently directly available on Future/Stream that may be upstreamed eventually.