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

Support into() for filter_map (Rust 1.12) #1764

Closed
saschagrunert opened this issue Oct 5, 2016 · 4 comments
Closed

Support into() for filter_map (Rust 1.12) #1764

saschagrunert opened this issue Oct 5, 2016 · 4 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@saschagrunert
Copy link
Contributor

Hey 👋 there,

What do you think of the idea of implementing the new From for Option for some libcore functions like filter_map? The benefit would be to return just a value T instead of Some(T).

Best regards,
Sascha

@SimonSapin
Copy link
Contributor

I assume you mean changing the return type of the closure in Iterator::filter_map from Option<B> to a generic O: Into<Option<B>>. The problem is that even if the return type is generic, for one given closure it has to be the same in all code paths. So any closure that sometimes returns B (taking advantage of the new From<B> for Option<B> impl) instead of Option<B> has to always do so and thus acts as if it were always returning Some(_: B). In that case there is no point in using filter_map, map could be used instead.

@saschagrunert
Copy link
Contributor Author

Ah okay so it makes no sense in any case?

@SimonSapin
Copy link
Contributor

I makes sense in that we could do it and it wouldn’t break things, but as far as I can tell it would never be useful.

@saschagrunert
Copy link
Contributor Author

Alright, thank you for the feedback.

@Centril Centril added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Feb 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

3 participants