A number of combinators are provided with identical names and similar semantics to methods on Option, Result, and Iterator. (e.g. map, map_err, and_then, filter_map, etc).
The standard library consistently places the new type that appears in Option/Result/Iterator first and the closure type second. futures-rs usually places the closure type first and the new type second. This difference is frustrating when type inference breaks down and the programmer has to turbofish their way to victory. Since a closure type can never be named, there's little reason to put it anywhere other than the end of the list. futures-rs is also not internally consistent, for example Future::map vs Stream::map.
I think you should copy the standard library convention across the board here.
I also wonder if this is too pedantic for a Clippy lint. CC @Manishearth
A number of combinators are provided with identical names and similar semantics to methods on
Option,Result, andIterator. (e.g.map,map_err,and_then,filter_map, etc).The standard library consistently places the new type that appears in
Option/Result/Iteratorfirst and the closure type second. futures-rs usually places the closure type first and the new type second. This difference is frustrating when type inference breaks down and the programmer has to turbofish their way to victory. Since a closure type can never be named, there's little reason to put it anywhere other than the end of the list. futures-rs is also not internally consistent, for exampleFuture::mapvsStream::map.I think you should copy the standard library convention across the board here.
I also wonder if this is too pedantic for a Clippy lint. CC @Manishearth