Change:
/// # Examples /// /// ``` <del> /// #![feature(option_take_if)] /// </del> /// let mut x = Some(42); /// /// let prev = x.take_if(|v| if *v == 42 {

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for adding similar to but requires an additional predicate. It the value if the predicate evaluates to . If the predicate evaluates to , the value of the remains . The predicate () also has the chance to modify the value. <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] ACP: rust-lang/libs-team [x] Implementation: [ ] Final comment period (FCP)[^1] [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- [x] Consensus seems to be to only implement but with [^1]: https://std-dev-
Is there a reason to have both and when we already have in ?

To be honest, personally I can't think of a concrete reason at the moment. has both () and I used it as impl orientation. The question would then also be which name to keep: or . A suffixed method without the corresponding not-suffixed one seems odd, but and a in the callback might be unexpected after using ? I am also not sure about all the stuff which I copied over from the impl. edit: I am totally fine with only and
Vec::retain is a mistake and should not be followed. I prefer keep 'retain' only with '&mut' signature.​
Done :)
Do you think there are further changes needed?
Signature looks good now, can't say anything about trait bounds though.
Hi! Any progress on this unstable-feature? It's not that big a feature and I'd like to use it so much that I'd like to move forward with the stabilization process if there are no major issues. Any concerns come to mind?
Hi I can't get a comment on whether it's ready to be stabilized, so I had to ping a member of the libs team! I'd be happy to have them review it.
The implementation is straightforward, but API goes to a different team -- anyone from want to comment?
I think this is a generally useful utility function that can make some use cases easier to write & more readable. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
What about ? Like but for :
I guess replaceif would be useful as well. It seems consistent that and be provided, just as and are provided respectively.
+1 for I've encountered several occasions recently when the implementation of for an combinator would have been much more concise and readable in these terms, to the point where I actually did write a crate-local trait. Glad to see it proposed in an unstable feature!

This may be starting to cross the "out-of-scope event horizon", but, similarly, I would like to see . The pattern of has a habit of cropping up independently in other places. The really could be and the could be . For instance, when conditionally mutating a shared object behind an , I'd rather not and potentially force a copy just to make the check to see if I have to. Or, when using one-or-more-layers of to avoid "ambiguous interacting sets of " or something. I want to do something in the case, but only when a predicate, but I need to pass on an , the else is always going to be , the calculation-after-the-predicate also returns an already, and I'd rather not break out of my method chain. Or (and I'm not joking), a function that returns an iterator in an which itself yields items in s and loops until exhausted then loops to call the original function again and loops until exhausted but breaks the loop and returns the of any of the should that happen. (That may sound insane, but, due to external constraints, I'm reluctantly rather confident that this is actually the most elegant/optimal it can get...) I'm a big fan of and . I will concede that it's possible to abuse/overuse them, but in some circumstances it really is the cleanest and most readable way to express what's happening. I think nicely rounds out the family. : Eager : Lazy : Lazy-but-could-be- You can sort of do this today, with but is silly, unsightly, and noise. The pattern could then turn into could then be expressible as and So, in a sense, may actually be a more fundamental construct than . So if gets in the language, I think it makes sense that would also.
Actually, I think may be the wrong semantics. closure takes an argument. It's a mapping from the type parameter of some type to . That doesn't really seem analogous to what's going on here at all. I guess got me thinking in the direction, and has a method called with a function parameter that returns self-but-with-a-different-parameter, so I it seemed like the first obvious choice. The implementation looks like Looks rather more like the of , so... maybe ?
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.