The critical thing to note here is that Option<T> and Result<T, E> are types, while Iterator and Future are traits, which explains why it would work straightforwardly for Option and Result but why it doesn't appear to work for Iterator and Future. If the return types on Iterator::flat_map and Future::and_then were written using the proposed -> impl Trait syntax (i.e. I return some unspecified type that implements this trait), they would look like -> impl Iterator<Item=U::Item> and -> impl Future<Item=B::Item>, respectively. If -> impl Trait was usable in traits, then I guess we'd need higher-kinded traits too in order to provide a maximally generic flat_map? The fact that types and traits are distinct in Rust makes this kinda tricky.
However, my experience shows that higher-kinded polymorphism will be more useful for type constructors taking lifetime arguments, rather than type arguments. I have answered three questions on Stack Overflow where somebody tried to write generic code that didn't work because they needed type constructors parameterized on a lifetime argument. Here they are:
- Lifetime parameter for
Selfin trait signature - Higher Ranked Trait Bound and boxed closures lifetime issue
- Cannot borrow variable when borrower scope ends
So if Rust implements higher-kinded types, it should minimally support type constructors with lifetime parameters; type constructors with type parameters would be a bonus.