Tracking issue for Option::filter (feature `option_filter`)

[dtolnay]

This is a tracking issue for Option::filter.

• Proposed in Add filter to Option rfcs#1485
• RFC written in RFC: Add Option::filter to the standard library rfcs#2124
• Initial implementation in Add Option::filter() according to RFC 2124 #44996 (not merged)
• Resubmitted in Add Option::filter() according to RFC 2124 #45863

Unresolved questions:

• decide on name (filter vs and_if vs …)

[LukasKalbertodt]

@dtolnay Could you add a task "decide on the name (filter() vs. and_then() vs. ???)" to your comment? Also: the PR is ready now.

[kennytm]

@LukasKalbertodt @dtolnay Updated.

[dtolnay]

I think and_if is a brilliant name. Really great idea and strong contender. At this point I would still lean toward filter.

I find that the and/or methods on Option make perfect sense and the names reflect what the method does, but it still takes me multiple seconds when I see something like or_else or map_or to reverse engineer what that means in terms of argument types and return types and pattern matching and behavior of my code.

In contrast, filter is strongly immediately associated with taking a filter function &T -> bool and using it to decide whether to keep the values in self. A short name with that sort of immediate strong association was not available for the things the and/or family of methods do, or they would have been called something different.

[nvzqz]

As I mentioned in #45863 (comment), I have a question regarding the signature of this method:

Wouldn't this method be more flexible if the FnOnce took &mut T?

My suggested change would differ from Vec::retain, which this method acts similarly to (except not in-place). Perhaps it would be worth considering changing the signature of Vec::retain too?

I understand that this method is essentially shorthand for option.iter().filter(predicate).next(). My suggested change would be equivalent to option.iter_mut().filter(predicate).next().

[netvl]

+1 for filter() - this also has precedents in other languages:

• Java: Optional.filter()
• Scala: Option.filter()
• Haskell: mfilter (a more generic function defined for the MonadPlus type class, but the name is still filter-based)

[LukasKalbertodt]

@nvzqz Do you have a specific use case in mind? Yes, the method would be more flexible with FnOnce(&mut T) -> bool as predicate, but we don't necessarily want this flexibility. Simple example: Rust variables are immutable by default in order to limit what you can do -- more flexibility/possibilities are not always a good thing.

So without good use case in mind, I would keep the signature as is: I don't think anyone would expect a predicate of a method called filter() to change the inner value.

[LukasKalbertodt]

About the name: please note that the RFC thread already contains quite a few arguments for and against certain names. I'll try to summarize the most important points here:

---

The two competing names are filter and and_if. One comment on their differences:

In other words, .and_if describes how it does X, .filter describes what X is. This is the distinction between imperative and declarative programming where the .filter is declarative.

Comparing the two:

	Advantages	Disadvantages
filter	Same as in most other languages Same as in Iterator	Makes you expect filter_map on Option Possible confusion about filter-in vs. filter-out (although in other languages, it's pretty much always filter-in)
and_if	Fits other methods of Option more closely More descriptive in the context of control flow	Name is not well known in the FP world Less descriptive in the context of data flow Signature not immediately clear from the name

---

How this method is called in other languages:

• Haskell: mfilter
• Scala: filter
• C++17: no such method (right?)
• boost::optional: no such method (right?)
• Idris: no such method (right?)
• Nim: filter
• Java8: filter
• Swift: no such method (right?)
• Python: filter (kind of)

[KodrAus]

It looks like we're still in the bikeshedding phase here, so just leaving a note to say I found my way here after typing .filter automatically and discovering the method exists and is unstable :)