Rename (Trait, TraitExt) pairs to (TraitCore, Trait)

[HyeonuPark]

In current API, most traits of futures-rs are splitted into 2 variants - one for implementors, and one for consumers. Formers are named without suffix, and latters are named with Ext suffix.

Ironically those pair traits are mostly disjoint in usage pattern. For example, a library which expose a type that impls Stream doesn't need to know about StreamExt trait in their code at all. And if I want to write a binary with heavy business logic, I don't want to care about poll_next() method so will only use StreamExt trait.

But in practice, there's way more library consumers than library writers, so most users only need StreamExt not Stream. I can easily imagin SO questions like "How can I map or filter on Stream type?" and correct answer for it is to replace use futures::stream::Stream with futures::stream::StreamExt. Of course we can recommend to use futures::prelude::* but some of them will complain about it as we all know the use-all pattern is considered bad in general.

That's why I'm suggesting here to remove suffix from consumer-side traits. The Core suffix I referred in title needs more bikeshedding though.

This issue is more like a RFC but I couldn't find a better place for it. Please let me know if this is not a right place for it!

[Matthias247]

The Ext things are not generally the for-consumer version. They are extension methods on the traits, and the convention for extension traits is to use Ext (rust-lang/rfcs#445). You can consume/use the traits just fine without the extension methods - then you don't have the methods available. In many cases that is sufficient.

The Stream/Sink/AsyncRead/AsyncWrite traits you mention are somewhat special in that regard, since they don't yet 100% fit into the async/await world natively by not returning Futures. Therefore those extensions might be required by more users.

[Nemo157]

Adding on to what @Matthias247 mentions, the "core" trait will still be heavily used in consumers. All generic APIs should be based on the core trait, and the extension is just brought into scope to provide extra methods on it. Because of that having the short name for the core trait is better since it will commonly be mentioned in multiple places per-file, while the extension trait will only ever be used once at the top of each file.

[cramertj]

Closing-- the current design is intentional.