Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make order of combinator function types consistent, reverse most of them. #517

Closed
khuey opened this issue Jun 17, 2017 · 1 comment
Closed

Comments

@khuey
Copy link
Contributor

khuey commented Jun 17, 2017

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

@alexcrichton
Copy link
Member

Fixed in 0.2 in #806

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants